SV: SV: [ubl] Revised discussion paper on UBL 2.0 subsets, extensions, versions, validation and interchange

["Bryan Rasmussen" <BRS@itst.dk>]

Hi Ken,

>At 2006-06-20 11:04 +0200, Bryan  Rasmussen wrote:
>I don't think this makes any sense:
>
>         <xs:element ref="u:Extension" minOccurs="0"/>
>         <xs:element ref="u:OrderNumber"/>
>         <xs:element ref="u:LineItem" maxOccurs="unbounded"/>
>         <xs:element ref="u:TotalAmount"/>
>         <xs:group ref="u:FutureVersions"/>
>
>>If we were allowing basically any at the end of the sequence then we would
>>have both the Extension as an Any, and at the end of the sequence Any
>>allowed? The only difference is that u:Extension is of course an element.

>Right ... but the FutureVersions group is for 
>minor version use only and not for subset use 
>(customization).  Customizations would still be 
>required to use the extension point for its declarations.

This is not something I'm suggesting, it is something that I am having a
problem to understand. But I understand it a little better now,
FutureVersions basically would be required to have a namespace version that
was a minor version of the documents major? Could be done relatively easy in
Schematron. 

>What was brought to my attention in the meeting 
>last night was that regardless of whatever rules 
>we state in prose regarding the use of the minor 
>version wild card area, since we cannot enforce 
>it with schema expressions, we can expect it to 
>be abused by users who throw their own constructs in that area.

Everything will of course be abused, not sure as to the extent of abuse. 
But I think we still want to protect against Abuse. 

>Is there a processor that accepts what you show 
>above to be acceptable for validating my 
>test? 

You're right as long as FutureVersions is unbounded of course, basically this
is another form of nondeterminism. It is to avoid these kinds of problems I
would rather see content not expected to be automatically understood as part
of the standard to be under an extension element.
 

>or
>>
>>           <xs:element ref="u:Extension" minOccurs="0"/>
>>        <xs:element ref="u:OrderNumber"/>
>>        <xs:element ref="u:LineItem" maxOccurs="unbounded"/>
> >        <xs:element ref="u:TotalAmount"/>
> >        <xs:element ref="u:Extension" minOccurs="0"/>

>I'm making a distinction between user-defined 
>extensions (the element extension point 
>u:Extension), and committee-defined minor 
>versions (the group u:FutureVersions).
I think this would be better used as metadata on an extension but I see your
part on this. 


>But during the call last night it would brought 
>to light this would be opening a can of worms for 
>those users of UBL who did not follow our 
>guidelines and who put their own constructs at the end of ABIEs.
yes this is basically what I find problematic. 

>>This is not an endoresement of using the methodology you've shown in your
>>paper which I worry will cause implementation problems, and am not
completely
>>sure if moving the Html method of handling unknown markup to a business
>>markup standard is a good idea, it's somewhat untried. But that is an issue
>>for a later post, although I might after thinking about it further become a
>>fan of the solution but right now I am worried.

>Remember that the HTML method of handling an 
>unknown element is to process the children of the 
>element ... I'm certainly not suggesting that 
>(nor is that easily constrainable in a schema expression).
Okay I had assumed this was part of your viewpoint because of previous
discussions, for example in Brussels. 

>How would you characterize the implementation 
>problems you think might be in play?
The only implementation problem I would worry about is if anyone was using
either:

1. non xml compliant parsers. sometimes people will do this to optimize
performance I suppose, but if that is the case then 
they should generate their parser from an xml parser generating kit and not
roll it by hand (personal opinion)
2. in xml compliant APIs etc. generic processing may be hampered, this
problem also exists with the extension element, but in that context extension
element content can be automatically removed before processing. 

>>Also if I understand what you're suggesting I think we could end up with
>>nondeterminism, for example if you had
>>
>>
> >        <xs:element ref="u:TotalAmount" minOccurs="0"/>
> >        <xs:group ref="u:FutureVersions"/>
>>
>>With this wouldn't you end up with a situation where u:TotalAmount either
has
>>to be validated as the default validation of the validator, prob. strict,
or
>>skipped, and how would you know which it was?

>I believe the particle determination is 
>unambiguous.  Do you have a running example 
>illustrating there is a problem with the 
>above?  I understand the validation will deal 
>with the particles in the order received, and 
>since there is no choice group I don't think 
>there is an opportunity for non-determinism.

This:
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"; 
  elementFormDefault="qualified" 
  targetNamespace="urn:x-oasis:Order-2" 
  xmlns:u="urn:x-oasis:Order-2">
  <xs:element name="Order">
    <xs:complexType>
      <xs:sequence>
       <xs:element minOccurs="0" ref="u:Extension"/>
        <xs:element ref="u:OrderNumber"/>
        <xs:element ref="u:LineItem" maxOccurs="unbounded"/>
        <xs:element ref="u:TotalAmount" minOccurs="0"/>
        <xs:group ref="u:FutureVersions"/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
  <xs:element name="Extension" type="u:Extension"/>
  <xs:element name="OrderNumber" type="xs:string"/>
  <xs:element name="LineItem">
    <xs:complexType>
      <xs:sequence>
        <xs:element ref="u:Description"/>
        <xs:element ref="u:PriceAmount"/>
        <xs:group ref="u:FutureVersions"/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
  <xs:element name="Description" type="xs:string"/>
  <xs:element name="PriceAmount" type="xs:string"/>
  <xs:element name="TotalAmount" type="xs:string"/>
  <xs:complexType name="Extension">
    <xs:sequence>
      <xs:any namespace="##any" processContents="skip" 
              minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
  </xs:complexType>
  <xs:group name="FutureVersions">
    <xs:sequence>
      <xs:any namespace="##any" processContents="skip" 
              minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
  </xs:group>
</xs:schema>

when run with this instance:
<?xml version="1.0" encoding="UTF-8"?>
<Order xmlns="urn:x-oasis:Order-2"
       xmlns:u="urn:x-oasis:Order-2"
       xmlns:u21="urn:x-oasis:Order-2.1">
  <Extension>
  </Extension>
  <OrderNumber>123</OrderNumber>
  <LineItem>
    <Description>747 Repair Kit</Description>
    <PriceAmount>1200000.54</PriceAmount>
    <u21:CountryOrigin>
      <u:Country>Xanadu</u:Country>
    </u21:CountryOrigin>
  </LineItem>
  <LineItem>
    <Description>DC3 Repair Kit</Description>
    <PriceAmount>37.25</PriceAmount>
    <u21:CountryOrigin>
      <u:Country>Zanzibar</u:Country>
    </u21:CountryOrigin>
  </LineItem>
  <TotalAmount>1200037.79</TotalAmount>
</Order>

produces this output in XSV210:
<xsv docElt="{urn:x-oasis:Order-2}Order" instanceAssessed="true"
instanceErrors="0" rootType="[Anonymous]" schemaDocs="kens.xsd"
schemaErrors="1"
target="file:///C:/projects/tests/installs/validators/xsv/kens.xml"
validation="strict" version="XSV 2.10-1 of 2005/04/22 13:10:49">
<schemaDocAttempt
URI="file:///C:/projects/tests/installs/validators/xsv/kens.xsd"
outcome="success" source="command line"/>
-
	<schemaError char="5" line="7" phase="instance"
resource="file:///C:/projects/tests/installs/validators/xsv/kens.xsd">
non-deterministic content model for type None: {Wildcard:
##any}/{urn:x-oasis:Order-2}:LineItem
</schemaError>
</xsv>


as noted "non-deterministic content model for type None: {Wildcard:
##any}/{urn:x-oasis:Order-2}:LineItem" the newer XSV however did not return
an Instance error, IIRC earlier XSV issues would have returned an error.

The same with MSXML's schemaCache:
---------------------------
Windows Script Host
---------------------------
Script:	C:\projects\tests\installs\validators\xsv\validate.js
Linje:	30
Tegn:	4
Fejl:
file:///C:/projects/tests/installs/validators/xsv/kens.xsd#/schema[1]/element
[position() = 1 and @name = 'Order']/complexType[1]/sequence[1]
Schema is non-deterministic.
[{urn:x-oasis:Order-2}LineItem]
Kode:	80004005
Kilde: 	msxml4.dll

---------------------------
OK   
---------------------------

The nondeterminism is because if LineItem minOccurs is 0 then if a LineItem
is found it can be validated either as a Strict or as a Skip, because Any
allows LineItem to be present as well. 



>>basically this is one of the reasons for using, instead of ##any namespace,
>>##other namespace,

>The limitations of W3C Schema semantics won't 
>allow me to say "##other" of the four UBL 
>namespaces ... only the one given namespace ... I 
>can say that in RELAX-NG but not W3C Schema.
I know, I tried to state that when I said:

>>however other namespace usage CAN also lead to
>>nondeterminism in cases where the sequence can hold elements in namespaces
>>other than the target namespace of the schema where xsd:any is used. 

>Really?  I understood that where only a single 
>##any was used the non-determinism would only be 
>in the case of a choice group and not a sequence 
>group. 

Nope as explained above. 

>Thank you, Bryan, for your post ... but from what 
>I can tell the concerns that have come to light 
>in your analysis may, indeed, not be concerns 
>based on actual tests engaged with available 
>processors. 

Well I didn't go and test because I was pretty certain on this particular
instance. 


Cheers,
Bryan Rasmussen