Hi William, Thanks for your comments. Please see my responses inline.
William Schumann wrote: > 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. The functional spec for the parser as defined in the document above doesn't include functionalities for dynamic defaults and semantic validation. A client application would first call the parser's init function to load the XML file into memory. Then, the app would call the dynamic defaults module to assign the default. Then, the app would call the parser's validate function to validate syntactically. Finally, the app would call the semantic validation module to validate the semantics. New parser works differently than ManifestServ where everything is assigned and validated when the manifest is parsed. The client application drives everything. >> >> 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? All the links at the end of the email are different framework for doing this sort of validation. >> 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 Yes, I agree. The checking of data in the XML "up-front" would certainly be useful. >> >> 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. That sounds good to me. >> 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). Well, isn't what you are suggesting kinda similar to the derived-manifest project? Except that the function to replace those replacement tags will be provided by the client application for filling in the defaults, instead of having users provide their own derivation functions for the derived-manifest project. What you are suggesting would make a given XML file much harder to read, IMO. Because it will expose implementation details to the user. The users who have to edit the XML manifests would be confused as to what those "replacement tags" are doing, since that's not something they can use. >> 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 We discussed this at the meeting today. Basically, if we port what is done by ManifestServ today, there's minimal benefit in terms of ease of maintaining the application, because the default setting and semantic validation provided by the parser is just providing the framework to calling the client-application-provided functions for these features. Additionally, the application would still need to maintain the node paths that points to things to be set/validated. So, we might as well move all the validation stuff to the actual client application. If code should be shared by different client applications for validating certain things, those code can be placed in a library. Clay suggested something that would allow the client-provided functions to be specified as part of the schema. If that works out, perhaps that's we can consider. Thanks, --Karen >> >> 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
