[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
Ok, after a bit of experimentation I think I (finally :-) agree with your conclusion. It rests with your point that an extension author may import UBL global types or elements into their schema, and, if the xs:any in the containing UBL schema has its processContents value set to anything other than 'skip', then those elements would also be validated (and thus may fail) which may/may not be what the TPs using the extension want to happen. Enjoyed the debate. Fraser. On 18/05/06, G. Ken Holman <gkholman@cranesoftwrights.com> wrote: > At 2006-05-18 13:57 +0100, Fraser Goffin wrote: > > >let me check something so that I'm sure we are not talking at cross purposes. > > Sounds good. > > >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). > > Well, individual parties would expect what is in an extension, but > governing bodies would probably not ... nor should they want to. > > >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. > > Indeed ... we are publishing a standard for open use without > governing anything about extensions beyond the influence they have in > our schemas which is limited to their apex elements being direct > children of our extension point. The rest is their business, not the > business of UBL. > > >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 ? > > Great ... then we agree. > > >Just checking :-) > > :{)} > > >This still leaves us with the choice of value for the processContent > >attribute of course. > > I don't think it leaves us a choice at all ... as you say "UBL should > have no knowledge of other 'stuff' that may be put into one of its > opaque containers" ... which includes stuff that might be using UBL > constructs for their own purpose. Extension stuff is anyone else's > purview, so the governing body better not interfere by saying > anything at all about the content of extensions below the apex. > > Again, the apex points cannot be UBL constructs because there is > nothing wrapping the UBL constructs to say how they are to be treated > as an extension. > > >>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 ? > > I think that's an orthogonal question, but yes UBL does follow the > "Garden of Eden" characterization of schema expression where all > elements and types are defined globally and there are no anonymous > types. Other characterizations of schema design patterns are termed > "Russian Doll" (document element is global, all other local, all > types local), "Salami Slice" (all elements global, all types local) > and "Venetian Blind" (document element is global, all other local, > all types global). > > One of our many reasons to thank Eve Maler: > > http://www.idealliance.org/papers/xml02/dx_xml02/papers/05-01-02/05-01-02.html > > I hope this helps. > > . . . . . . . . . . . . Ken > > -- > Registration open for XSLT/XSL-FO training: Wash.,DC 2006-06-12/16 > Also for XSL-FO/XSLT training: Minneapolis, MN 2006-07-31/08-04 > Also for XML/XSLT/XSL-FO/UBL training: Varo,Denmark 06-09-25/10-06 > World-wide corporate, govt. & user group UBL, XSL, & XML 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]