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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev message

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