[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-dev] Re: [xml-dev] Re: [ubl-dev] UBL 2.0 and Schema Extensibility
Ken, let me check something so that I'm sure we are not talking at cross purposes. I am talking about the validation of content within any extensibility point allowed in a schema (any schema, not just UBL) being performed by the parties that have apriori knowledge of what their expectations of that content should be (they each have a schema that describes it). I was starting to get the feeling in this last discourse that you were talking about what you would expect a 'UBL aware' validation approach should be and what 'it' should reasonably know about or not. In this case I would agree that any validator that is only concerned with compliance to UBL should have no knowledge of other 'stuff' that may be put into one of its opaque containers ? Just checking :-) This still leaves us with the choice of value for the processContent attribute of course. > Only the apex of the extension, the immediate child of the UBL > extension point, has to be non-UBL. What is in each subtree under > each apex being an immediate child of the extension point is free > game ... including any bad practices or conflicting interpretations > ... after all, the extender used the extension point to get away from > the standardized schema ... why pollute that environment by saying > "well, though you are in charge of your extension I'm still going to > impose this on you that you pass my other constructs however you use > them"? The more I try to describe this, the more certain I feel about this. H'mmm, ok, I'm starting to understand where you're coming from here. Educate me a bit here. Is UBL defined principally of global elements/types ? Fraser. On 18/05/06, G. Ken Holman <gkholman@cranesoftwrights.com> wrote: > At 2006-05-18 00:20 +0100, Fraser Goffin wrote: > > >>I'm appreciating this discourse, Fraser > > > >Cool, I'll continue then. > > Great ... getting perspectives is important. > > >>... but back to your point about using "lax" instead of my > >>suggested "skip" ... if it were true there were no UBL elements > >>inside of the extension, and UBL is the only schema being used in > >>validation, there is no difference between "lax" and "skip" because > >>nothing in there would be recognized. > > > >The content of the extension *will* be recognised by any party who has > >the schema that defines it, and 'lax' then enables that content to be > >validated as normal by a standard validating parser (structurally at > >least). > > Yes, I know ... and that is what worries me. Given the mechanics of > redefine and overriding schema fragments, I'm not sure how one would > invoke W3C Schema semantics for the lax contents of the black box > with the read-only UBL schemas. > > >I guess my somewhat laboured point about the 'lax' versus 'skip' > >debate is that with 'lax' I at least have the opportunity to valiadte > >content if I happen to have the schema (i.e. I am interested in that > >extension). > > But I posit you should only be interested in an *entire* subtree of > the extension from the extension point down because, as a black box, > anything below the point of extension might be governed by other > bastardized schemas *in the same namespace* (not a good practice, but > I'm not trying to be a policeman here). > > >If 'skip' is the vlaue for processContents then the schema > >author is effectively denying me that opportunity for some 'free' > >validation, and forcing me to either implement some other mechanism, > >or just hope for the best :-( . > > My perspective of validation is "all or nothing" not "pick and > choose". I'm abdicating the responsibility for a subtree under the > extension point whose apex is in another namespace so that I have no > preconceived notions of the meaning of the apex of the > extension. That means I must also have no preconceived notions of > the contents of the subtree because the subtree is, I believe, > *entirely* the purview of the extension. > > >Its a minor point perhaps, > > No, I think this is quite major and I'm trying to anticipate (without > there being real-world experience in this yet) where we will trip > over things, and I'm feeling quite certain that any inadvertent > attempts to presuppose the structure of something inside of an > extension to have to follow the constraints expressed for the content > outside of the extension is fraught with problems. > > >but I > >don't see why a schema author should explicitly exclude any available > >mechanism that I may choose to use (and I don't wnat to change that > >value in the schema, because I am not the schema author). > > Because the validation of the extension is a separate responsibility > than the validation of the instance with the extension point. *Just > in case the extension has a competing structure for whatever reason > by design of the extender*. > > If it happens that the extension includes the same structures, then > the despatched validation of the extension will worry about that. > > >>But, since the content may > >>have bastardized UBL inside, using "skip" would prevent false > >>negatives when using "lax". > > > >Would it ?. The extension may have a 'UBL like' content model, but it > >definately won't be UBL since it will be defined in a non UBL > >namespace and therefore won't be validated against any UBL schema will > >it ? > > Only the apex of the extension, the immediate child of the UBL > extension point, has to be non-UBL. What is in each subtree under > each apex being an immediate child of the extension point is free > game ... including any bad practices or conflicting interpretations > ... after all, the extender used the extension point to get away from > the standardized schema ... why pollute that environment by saying > "well, though you are in charge of your extension I'm still going to > impose this on you that you pass my other constructs however you use > them"? The more I try to describe this, the more certain I feel about this. > > >The example schema fragment that you pointed at :- > > > > <xs:choice minOccurs="0" maxOccurs="unbounded"> > > <xs:any namespace="##other" processContents="skip"/> > > <xs:any namespace="##local" processContents="skip"/> > > </xs:choice> > > > >looks OK, but XML Spy and MSXML 4 report it as non deterministic ? > > The latest Xerces using xjparse works just fine (transcript > below). Hmmmmmm ... not sure how to arbitrate that one ... I hate to > rely on vendors' tools to say what is "correct". Let me think who > might offer an opinion. > > Thanks, Fraser! > > . . . . . . . . . Ken > > t:\fraser>type exublorder2.xsd > <?xml version="1.0" encoding="UTF-8"?> > <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"; > elementFormDefault="qualified" > targetNamespace="urn:oasis:names:draft:ubl:schema:xsd:Order-2" > xmlns:u="urn:oasis:names:draft:ubl:schema:xsd:Order-2"> > <xs:element name="Order"> > <xs:complexType> > <xs:sequence> > <xs:element ref="u:OrderNumber"/> > <xs:element maxOccurs="unbounded" ref="u:LineItem"/> > <xs:element ref="u:TotalAmount"/> > </xs:sequence> > </xs:complexType> > </xs:element> > <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:element minOccurs="0" ref="u:LineItemExtension"/> > </xs:sequence> > </xs:complexType> > </xs:element> > <xs:element name="Description" type="xs:string"/> > <xs:element name="PriceAmount" type="xs:string"/> > <xs:element name="LineItemExtension" type="u:any-non-UBL"/> > <xs:element name="TotalAmount" type="xs:string"/> > <xs:complexType name="any-non-UBL"> > <xs:choice minOccurs="0" maxOccurs="unbounded"> > <xs:any namespace="##other" processContents="skip" > minOccurs="0" maxOccurs="unbounded"/> > <xs:any namespace="##local" processContents="skip" > minOccurs="0" maxOccurs="unbounded"/> > </xs:choice> > </xs:complexType> > </xs:schema> > > t:\fraser>type exaeroorder2.xml > <?xml version="1.0" encoding="utf-8"?> > <Order xmlns="urn:oasis:names:draft:ubl:schema:xsd:Order-2" > xmlns:a="urn:x-aerospace:ubl:lineitem"> > <OrderNumber>123</OrderNumber> > <LineItem> > <Description>747 Repair Kit</Description> > <PriceAmount>1200000.54</PriceAmount> > <LineItemExtension> > <a:LineItemDetail> > <a:Part> > <a:Description>Starboard wing</a:Description> > <a:Amount>600000.00</a:Amount> > </a:Part> > <a:Part> > <a:Description>Port wing</a:Description> > <a:Amount>600000.00</a:Amount> > </a:Part> > <a:Part> > <a:Description>Bolt</a:Description> > <a:Quantity>2</a:Quantity> > <a:Amount>.27</a:Amount> > </a:Part> > </a:LineItemDetail> > </LineItemExtension> > </LineItem> > <LineItem> > <Description>DC3 Repair Kit</Description> > <PriceAmount>37.25</PriceAmount> > <LineItemExtension> > <a:LineItemDetail> > <a:Part> > <a:Description>Rubber band</a:Description> > <a:Amount>37.25</a:Amount> > </a:Part> > </a:LineItemDetail> > <hello xmlns=""> > <world/> > </hello> > </LineItemExtension> > </LineItem> > <TotalAmount>1200037.79</TotalAmount> > </Order> > t:\fraser>xjparse -S exublorder2.xsd exaeroorder2.xml > No validation errors. > > > -- > 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 > 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 > > > --------------------------------------------------------------------- > This publicly archived list supports open discussion on implementing the UBL OASIS Standard. To minimize spam in the > archives, you must subscribe before posting. > > [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ > Alternately, using email: list-[un]subscribe@lists.oasis-open.org > List archives: http://lists.oasis-open.org/archives/ubl-dev/ > Committee homepage: http://www.oasis-open.org/committees/ubl/ > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php > Join OASIS: http://www.oasis-open.org/join/ > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]