[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xml-dev] Still banging on about extensibility and validation
At 2006-05-03 18:28 +0100, Fraser Goffin wrote: >Ken, > >a while back you made this interesting observation as part of a larger >conversation about message validation :- > >>There are some who hold with a traditional view that the entire >instance *has a model*, rather than the different view that sets of >labeled information found in an instance *each have their own model*. >And those sets are identified unambiguously through the use of >namespace-rich labels. > >>Accommodating "the entire XML instance has a model" is, I believe, >more difficult, time consuming and frustrating than accommodating >"each set of information found in an XML instance has its own model". > >I really want to believe this (in the practical sense of it being >implementable - now) I believe it is. A new open-source implementation of ISO/IEC 19757-4 NVDL has been announced and I added reference to it to the http://www.nvdl.org home page. I have been told of others being in the works. I have already added it to my training material and will be teaching it this summer in an XML document modeling introduction at a conference. >but there are a few pieces missing from my >understanding which are still troubling me, perhaps you (and others) >can help me out (the recent UBL SBS discussions are also surfacing >some really interesting commentary). (I agree ... about the commentary, not about you having any missing pieces!) >Anyway, as you had mentioned to me earlier wrt UBL code list value >validation, the validation processing *must* first test that a message >is compliant to the structural model (i.e. schema - maybe) before >value-based validation is attempted. I think the reason was/is to >confirm that the expected locations for values are present ? Indeed ... otherwise the second test is meaningless. If an assertion in the second test doesn't fail because an expected information item is in the wrong place, you would get a "false positive". >Also, that UBL schema do *not* use the xs:any or xs:anyAttribute >wildcard mechanisms for extensibility, I can now say *did not* because recent work concluded that it will be allowed in UBL 2 with a new element called UBLExtension: http://lists.oasis-open.org/archives/ubl/200604/msg00077.html >and in one sense UBL does not >support structural extensibility by trading partners (although >restriction is). This may be not entirely accurate so 'flame away'. I think it more accurate to say that W3C Schema redefine does not allow what is needed. >It may also be a bit unfair of me to put this sort of question to you >directly since you have already said you're really involved in the >code list stuff for UBL rather than the general schema work - so apols >for that :-) Not a problem ... I am taking a shared lead position in both task groups (which unfortunately puts my HISC work that I chair at risk for output forms ... I co-chair the SBSC work with Stephen Green who does the heavy lifting for that subcommittee) >So, this got me thinking about how, on the one hand we want to enable >trading partners to not be constrained in terms of any additional >'private' information items they may want to exchange, whilst at the >same time benefit from the broader reach of standards compliance. Now private information can be placed in the UBLExtension element, provided the immediate children of the element are not in the UBL namespace (though other descendants may be). And I suggested that we put this extension element at the very top of the instance so that applications using stream-oriented APIs such as SAX will be aware of the presence of any extensions before they have to deal with any standardized content. Note that we have provided for only a single point of extension for every instance. >If structural conformance is demonstrated by validating message >instances to UBL schema (I mean actual XSDs - for the moment), then >does that mean that :- > >a. there is no possibility for trading partners to 'insert' any >private data into a UBL specified content model (as foreign namespaced >items) even if that context make the most sense, since the message >would then be schema invalid ? Now there is ... with UBLExtension any private use under that element will pass structural validation. And with my proposed use of NVDL, the children underneath and their descendants can be despatched for validation with their own schemas. >b. if the approach is to validate aspects of the message rather than >the message as a whole, what does that mean in terms of a message that >is a composite of a number of a business entity based schema, doesn't >the context of where these individual parts exist in the overall >message typically lend as much to validation as the individual part >itself ? I believe context does, but when weighed against complexity, I was voted down, thus resulting in only the one point of extension. I contended other useful points of extension would be with parties and with line items, thereby using context to convey information about the extension, but this is not being allowed. When using the extension, the extension designer must find a way to associate their information items with the information items in the standardized locations. >c. if vocabularies are best developed in a way which allows >information items that are not part of its specification to be 'safely >ignored' (this has been a bit of a theme that has been coming through >recently), then is that really saying that traditional methods of >validating messages (i.e. validating parsers which load up XSDs) won't >really work, we need to move to validation via positional/context >based rules (XPath) ? Or, I think more appropriately, NVDL, since we are still talking structural constraints. Positional/context based rules using XPath files or ISO/IEC 19757-3 Schematron or other assertions are, I believe business constraints and coded value constraints, not structural constraints. Structural schemas are still, I believe, most appropriate for structural constraints. >d. what about NVDL, (or possibly CAM and/or other methods that are >being talked about). I think ISO/IEC 19757-4 NVDL is the mechanism by which we can safely look at XML instances using the view that sets of labeled information found in a single instance *each have their own model* ... those sets identified unambiguously through the use of namespace-rich labels. This is not achievable with the traditional view that the entire instance *has a single model* that is sacrosanct. The real world does not accommodate this traditional view well when trying to accommodate different users' needs. I cannot comment on CAM as there are just not enough hours in the day to be following everything that is out there and I am not equipped to provide a judgement on it or to explore its applicability. David Webber is the CAM expert, not me, and I respectfully defer to him for any CAM judgement. In my sphere of influence as the ISO/IEC JTC 1/SC 34 Secretariat Manager, I am far more focused on the ISO standards. I hope this helps. . . . . . . . . . . . . Ken -- Registration open for XSLT/XSL-FO training: Wash.,DC 2006-06-12/16 Also for XSLT/XSL-FO training: Minneapolis, MN 2006-07-31/08-04 Also for XML/XSLT/XSL-FO training:Birmingham,England 2006-05-22/25 Also for XSLT/XSL-FO training: Copenhagen,Denmark 2006-05-08/11 World-wide on-site corporate, govt. & user group XML/XSL training. G. Ken Holman mailto:gkholman@CraneSoftwrights.com Crane Softwrights Ltd. http://www.CraneSoftwrights.com/u/ Box 266, Kars, Ontario CANADA K0A-2E0 +1(613)489-0999 (F:-0995) Male Cancer Awareness Aug'05 http://www.CraneSoftwrights.com/u/bc Legal business disclaimers: http://www.CraneSoftwrights.com/legal
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]