Jack, 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. 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? In the AI client discussions of XML parsing, we concluded that the functional spec should describe features and that details of implementation should be addressed in the next step of design. However, mentioning existing functionality that is not ported as well as how new functionality is useful to DC might be interesting.
What should perhaps be made clearer is the more general notion of application-specific validation, which seems to be encompassed by "semantic validation". Each consumer will have its own semantic validation, and there must be methods for consumers to define the semantic validation. Either describe what these semantic validation methods will be, or just mention that they need to be provided and address them specifically in the next phase of design. > 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. "schema validation" to me means validation of the schema itself - the .rng file. Suggest the phases: - schema validation - is the .rng valid? - syntactic validation of the manifest - is the XML manifest compliant with the schema? - semantic validation of the manifest, e.g.: -- is the information in the tags syntactically correct according to how it is to be used? -- do the tags make sense in the way they are to be used in combination with other tags? > > Section 6.3 > - I think you need to describe how the different finalizer scripts in > DC access the schema values. The Finalizer is not mentioned at all in this func spec. I presume that specifying the use of the Finalizer is considered out of scope - is it? William > > 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 > > _______________________________________________ > caiman-discuss mailing list > caiman-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
