OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

[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]