Karen,
Karen Tung wrote:
> The XML parser functional specification for the new parser indicates
> that the
> dynamic default setting and semantic validation will no longer
> be a built-in feature in the parser.
> http://www.opensolaris.org/os/project/caiman/XML_Parsing/xml_1_func_spec.1.pdf
>
>
OK, so the dynamic defaults will be inserted first, then parsed and
validated against the schema, then validated for semantics and
user-specific cases, I'd assume.
>
> Since DC uses the default setting and semantic validation feature
> of the existing parser (ManifestServ), and there's a requirement from the
> AI client redesign team to perform semantic validation of AI manifests,
> I have done some research on how we might offer dynamic default
> setting and
> semantic validation in the new parser.
>
> ManifestServ provides an infrastructure for default setting and
> semantic validation
> to happen when the input XML is parsed. Basically, the framework
> allows you to
> specify the list of functions to be used for default setting or
> validation,
> and then, associates a given node in the XML tree to one or more of
> these functions.
> While this works, and can be extended to use with the new parser,
> I want to check whether there are any standards for specifying default
> setting
> and semantic validation.
>
Would you please provide references to documentation for this validation
framework?
> I did not find anything for doing default setting, but I found many
> links related to
> semantic validation. However, all the standards for semantic
> validation seem
> to have a slight different meaning than the way we use it in
> ManifestServ.
> All references to semantic validation refers to validating contents of
> different
> fields within the same docuement based on some constrain or validating
> constrains between
> fields in different documents.(see references below)
>
> This is slightly different than our definition of semantic
> validation. In our existing
> usage model, we can validate between different fields in the same
> document, or
> between different documents. We can also validate the given data
> against any context
> or rules. Basically, since we offer a way for people to plug-in their
> own function, they
> can write their function to validate against anything that they want.
Yes, it would be useful to have XML validated:
- semantically
- with additional type checking for tags that are not covered by the
standard schema types, including Solaris-specific tags and user-specific
tags
>
> Since our usage for "semantic validation" is slightly different than
> what all the
> standards specify, I think that we should come up with a slightly
> different term
> to describe what we do, so that there's no confusion about the
> functionality that
> we are offering.
>
> Based on my research so far, I couldn't find a better way to set up
> the infrastructure to
> do dynamic default setting and semantic validation. So, I am going
> to define
> the interface for the dynamic default setting and semantic validation
> modules for the
> new XML parser to be similar to the ones that's used for ManifestServ.
>
> I would need your feedback on:
>
> 1) Whether we should have a new name term to describe what we do for
> semantic validation?
> If so, your suggestion on the name.
How about supplementary validation? It would consist of semantic
validation plus any validation of other special datatypes or
user-specific validation.
> 2) If you have better ideas for setting up the dynamic default setting
> and semantic validation,
> I would like to hear them.
For approaches to dynamic default settings, search for references to
"replacement tags". Replacement tags are markers that can be scanned
for and replaced. You start with an XML or XML-like document, sometimes
referred to as a template, that contains the replacement tags that will
be replaced by valid XML. If there is a simple 1:1 replacement for tags
and text, this can be quite simple. Also you may want to look at XSLT,
a language for transforming XML documents. libxslt(3) is supported in
Solaris for use in conjunction with libxml(3).
> 3) Do you think it is worth having dedicated modules for doing
> dynamic default setting and semantic validation? An application can
> easily
> have similar structure set up in the code after the data is parsed.
The application might be easier to maintain and run, too.
William
>
> I would like to discuss this during tomorrow's meeting.
> Please feel free to send your comments before or after the meeting too.
> Please send all your comments by 6/17/2009 COB as I will start the
> functional spec at that time.
>
> Thanks,
>
> --Karen
>
> ------------------
> References:
>
> - http://www.clixml.org/index.html
> - http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1703998
> - http://lci.cs.ubbcluj.ro/ocle/um/xmlvalidation.htm
>
>
>
>
>
>
>
> _______________________________________________
> caiman-discuss mailing list
> caiman-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
