Hi Karen. Thanks for your comments. My responses are inline...
On 06/12/09 13:48, Karen Tung wrote: > 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. I envision interfaces which will be similar to what currently exists, except: - XPaths would be used instead of paths in their current form. This is just a different syntax of expressing the same paths. - The current "one call does it all" :) setup will be replaced with separate calls for validation, etc. - The dynamic defaults setting and semantic validation would be layered on top of the parser. Existing defval code would have to be ported to use the parser interfaces to extract information and install new values, but I'm envisioning near 1:1 call replacements to what is already there. The parser interfaces listed in the spec have been augmented to contain the necessary hooks for this. Shouldn't be a big deal. (I know... famous last words...) > What would need to be ported > in the current DC code to use this new parser? The DC proper currently instantiates the ManifestServ object and makes calls on it to start the socket server and retrieve data. These calls would have to be replaced as I mentioned above, but all of this functionality is in the spec and the interfaces outlined are similar to ManifestServ's. > Is there any existing DC functionality > that won't be ported? Not as far as the parser is concerned. > Any new functionality in this parser that can improve DC? There will be a more flexible grouping mechanism which could be used, although using it for more complex groupings may require more complicated calls (not sure). (An example of a more complex grouping is to return all children under a particular element.) For the simple case which is what DC does now, it will be easy.) > > - 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? The remote server module is what the client hooks into to retrieve data. I called it a server as it serves data to the client. Clients (e.g. finalizer scripts) would run a program which calls into this module to retrieve data from the primary server. > How are clients going to use this server module? See above. > > 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. OK. Will change to: "the selection of an XML parser which is well suited to AI and its ancillary projects (such as DC), and subsequent installer projects moving forward..." > > 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. I don't think it is necessary in this section, but I added the following short blurb: ... This includes load and save of data, and search/read/write access to the data from the primary consumer (holder of the data); and search/read access to the data from remote consumers. > > Section 1.4.1, the description of DC > - DC also has a requirement to be able to query the data from separate > programs. Yes, that is what the remote server module is for. > > 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. OK. I wasn't clear on when the operations were done. Saving isn't part of setup functionality, but is to be done later. I've changed that bullet from "setup" to "setup/save." > -Is the ability to save a new copy of the XML file a functionality > that need to be > included in the Primary Server Module? It is. See above. > > 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? I changed the description to say these are standalone programs and went into what kind of inputs they take and how they take them. > > 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? Thanks, no. I changed "represents" to "images", to infer that the tree isn't copied. > > 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. I'll adjust my use case, as the server only does derived manifest stuff during a dry run. Removed saving of the tree for the AI server case. > > 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. It doesn't really matter, but, that said, it is probably cleaner to do schema validation first. After schema validation, things are in their correct place for semantic validation to work. Also, schema validation may not be as rigorous as semantic validation. > > Section 6.3 > - I think you need to describe how the different finalizer scripts in > DC access the schema values. Done. Thanks again. Updated version has been posted at: http://www.opensolaris.org/os/project/caiman/XML_Parsing/xml_1_func_spec.2.pdf > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/caiman-discuss/attachments/20090616/2e86bde2/attachment.html>
