[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl] Schematron demo
Because of my limited availability, I have only a brief response to some of the points. At 2005-08-30 07:53 -0400, Burnsmarty@aol.com wrote: >I think there are pros and cons to the proposed approach. I have >some some brief analysis and offer the following thoughts for >discussion. Some of the answers can probably be provided through >refinements to the method. Others may be more problematic. > >The Good Stuff: >A single description in Schematron tests all instances of type 2 >(code list as attribute) usage. > >UBL schemas don't have to accommodate code list extensibility. > >More Problematic: >The schematron tests for attribute name and therefore bypasses the >use of the context of the schema -- therefore it can ignore the >schema's constraints. For example, what if the schema designer wants >to constrain the values in a particular usage but not others. XPath addresses this. Note in Jon's demonstration how the "currency-value" rule is declared to be abstract and is only made concrete by the use of a non-abstract rule with a context= attribute. The demo uses a wildcard context="*[@amountCurrencyID]" but could easily just as well use context="cbc:TotalTaxAmount" instead for a more focused context. >Approach is namespace insensitive. Only the demonstration is namespace insensitive, one could easily just as well use context="cbc:*[@amountCurrencyID]". >How does one detect that an instance file is based on an extended code list? Business rules and the choice to apply a given set of assertions. >How can one tell in the instance file what code lists are being used? One could base the context on the presence of the code list support attributes: context="*[@amountCurrencyID][@amountCurrencyCodeListVersionID='0.3']" >How does one detect that the correct version of the code list is being used? Specific values can be checked with the above, or one could report an error that a given version isn't being used: <assert test="amountCurrencyCodeListVersionID='0.3'"> >Where is the code list itself? It is an instance of the upcoming code list schema and is input to an automated process to produce the .sch set of assertions. >What does an extension document look like? What is an "extension document"? In Schematron one merely enumerates the desired conditions that must be true or the desired conditions that must not be false. >What does a restriction document look like? What is a "restriction document"? Are you speaking of expressions that extend or restrict an instance of the upcoming code list schema? I would leave such a question to Tony in regard to his proposed code list instance expression. >How is versioning handled? Versioning of what? >Still need to develop: >xslt that translates code list in XML to schematron form. When we decide what the code list instance looks like, and then what a proforma Schematron set of assertions looks like, the XSLT should be easily created. It would be a waste to start writing stylesheets before knowing the inputs and the outputs. I don't have any concerns that if we know the inputs and the outputs that an XSLT can be created to use for illustration. >Examples of schematron to handle type 1 (code list as element) My recollection of "type 1" is that being an element is not an aspect of its distinction. However, because everything is XPath, one can just assert test=".='CAD'" instead of test="@amountCurrencyID='CAD'" ... and as I mentioned earlier the implementation of Schematron I'm using appears to be old and deficient and I'm trying to find an implementation of ISO Schematron where the tests can all be based on the current node and the contexts can be set to either an element or an attribute. >Construction of schematron to handle all validation of ubl instance >documents. Schematron is only tasked with value validation and not structural validation, though if necessary, Schematron can be used to constrain structural validation that may be loosely defined in other schema expressions. >How complex will this be? Is there any processing resource demands >imposed by this method. I'm not sure what you are asking. As Jon illustrated, one only need change the synthesized XSLT stylesheets whenever the set of assertions changes. If the assertions do not change, one can use the previously synthesized XSLT stylesheet. For as many sets of assertions (and many assertions can be grouped into sets) as one has, one runs the synthesized XSLT stylesheet for that set. The processing demands can be estimated by the weight of running XSLT. I hope this helps. . . . . . . Ken -- 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/o/ Box 266, Kars, Ontario CANADA K0A-2E0 +1(613)489-0999 (F:-0995) Male Cancer Awareness Aug'05 http://www.CraneSoftwrights.com/o/bc Legal business disclaimers: http://www.CraneSoftwrights.com/legal
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]