Hi Jack, Here are my comments:
Overall comments: - Since this parser will be "the one and only" parser for all the install technologies going forward, I think there should be more discussion on how this change would affect the existing DC, which uses a different parser than the one proposed. What would need to be ported in the current DC code to use this new parser? Is there any existing DC functionality that won't be ported? Any new functionality in this parser that can improve DC? - The "Remote Server module". From reading the document, it is not clear to me how it is going to be used. A few immediate questions that come to mind are: Is it going run as a server? Who starts the remote server module? How are clients going to use this server module? Specific comments: Section 1.2, bullet 1, "the selection of an XML parser which is suitable for AI and its other aucillary projects....." - I thought this is going to be the "one and only" parser for all different install components, and AI is just one of it's consumers. I think it is more clear to explicitly say something along those lines. Section 1.2, bullet 2, "A list of required capabilities the parser must provide for consumers" - It would be good to list the different capabilities that is needed by all known consumers. I think you kinda do that a little bit in section 1.4.1 when you are describing the consumers. It will be more clear to have an explicit list of items. That way, it will be easy to make sure all required functionalities are captures, and people can easily evaluate whether the functionalities proposed in the spec would meet all the required functionalities. Section 1.4.1, the description of DC - DC also has a requirement to be able to query the data from separate programs. Section 2.1, the "setup" description for Primary Server Module - Why is it necessary to save a formatted copy of the data during setup? I would think that it is more useful to save a copy of the data after some operation is performed on the data. -Is the ability to save a new copy of the XML file a functionality that need to be included in the Primary Server Module? Section 2.4: - Even with these description, it is still not clear to me how I would go about doing testing using these modules. Do I write a program to specify a XPATH to see whether I can retrieve the elements or values that I want or can I do that directly or something else? Section 5.2.1, first sentence, ".....gains access to the data tree on the primary consumer by creating an object which represents the data tree..." - Is the remote server module going to make a copy of the tree? Section 6.1 - My understanding of the Derived Manifest project is that all the fields in the manifest will be derived on the client side. On the server side, only syntactic validation is performed. Section 6.2, item 5 and 6 Section 6.3, item 3 and 4 - Why is schema validation done at this step? After semantic validation? I would think that schema (syntactic validation) is done before semantic validation. Section 6.3 - I think you need to describe how the different finalizer scripts in DC access the schema values. Thanks, --Karen Jack Schwartz wrote: > Hi everyone. > > Here is a first cut of the functional spec for "XML Parsing: Parser". > It defines at a high level the functionality it makes available to an > XML consumer. > > Functional interfaces are outlined to be similar to what is currently > delivered by ManifestServ, but with the following changes: > > - Validation is kept separate from initialization, so that in-memory > data can be filled in and/or changed before validation. > > - Paths are Xpaths > > - Functional interfaces include adding, deleting and replacing nodes > in the tree. > > - Dynamic default setting and semantic validation is considered out of > scope of this specification and thus not defined. Sufficient hooks > are left in at this SW level so that this functionality can be layered > in above it. > > > There is one XXX regarding how to iterate through the entire tree, but > hey, this isn't the final version :) > > Please send your comments / feedback by Monday 6/15 lunchtime if > possible. > > http://www.opensolaris.org/os/project/caiman/XML_Parsing/xml_1_func_spec.1.pdf > > > > Thanks, > Jack > _______________________________________________ > caiman-discuss mailing list > caiman-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
