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


> I'm appreciating this discourse, Fraser

Cool, I'll continue then.

>... 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).

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). 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 :-( .   Its a minor point perhaps, 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).

> 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 ?

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 ?

Fraser.


On 16/05/06, G. Ken Holman <gkholman@cranesoftwrights.com> wrote:
> At 2006-05-16 22:12 +0100, Fraser Goffin wrote:
> >>But what if a black-box use of a UBL construct violates UBL ...
> >>perhaps because the UBL construct has a required child, but that ...
> >
> >Hang on, I thought the proposal for extensibility in UBL 2 is to allow
> >either foreign namespace or no namespace content.
>
> ... as a direct child of the extension element ... what is inside and
> underneath can be anything at all, including UBL 2 or bastardized UBL
> 2 since it isn't governed by the same schemas.
>
> By forcing non-UBL as children of the extension, you are guaranteed
> that no-one can put naked UBL as a child of the extension and have it
> mean anything ... it would only mean anything in the context of a
> non-UBL ancestor being the child of the UBL extension.
>
> >In either case this
> >is *not* UBL, this is content that has been agreed by the parties that
> >are communicating and declares itself to have meaning only to those
> >parties.
>
> Sure.
>
> >It is a 'black box' to everyone else since they won't have
> >'that' schema. They may of course be using their own.
>
> Each would have their own, yes.
>
> >So this is
> >extensibility for non schema owners, in this case everyone other than
> >the UBL TC.
>
> True ... 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.  But, since the content may
> have bastardized UBL inside, using "skip" would prevent false
> negatives when using "lax".
>
> >I don't see how any of this violates UBL since UBL is allowing
> >arbritary content to be located (but declared explicitly as *not*
> >being actual UBL) at specific locations in its content model.
>
> Sorry, again I wasn't clear ... what I meant was that if an extension
> utilized a UBL construct that itself wasn't valid with the UBL
> schemas but was valid in the extension schemas (I'm not saying it is
> a good practice, but I can imagine someone "borrowing" a UBL
> construct and subsetting it for extension purposes to the point of it
> not being valid to the original UBL).
>
> >Am I missing something here (I'm only on rumours about how
> >extensibility will be introduced in UBL 2 since nothing appears to
> >have been published officially as yet) ?
>
> Just that inside the extension element is free game ... which might
> for some include invalid UBL constructs ... which I wouldn't like to
> see "caught" by using "lax" for the validation of the extension
> element (and I'd love to write more about extensibility but the UBL 2
> schemas that support extensibility won't be completed until some time
> after next week's plenary UBL session in Brussels ... which also
> gives time to NVDL vendors to come out of the woodwork and improve
> their products ... I'm quite excited to write about and demonstrate
> the extensibility as I'm teaching it in August in the hands-on UBL course.
>
> >Maybe your saying that the content model of the extension may itself
> >use constructs defined by UBL.
>
> Yes, indeed I am.
>
> >But in that case wouldn't that violate ##other ?
>
> No, because my understanding is that ##other applies only to the
> child elements of the extension element, and by saying "skip" then
> anything can be used inside those child elements because they are not
> being validated in any way.
>
> >and if you put it in your own namespace then really its not UBL even
> >if it looks remarkably similar and the intended semantics
> >are identical ?
>
> Correct because one wouldn't be using the UBL schemas to validate it,
> they would be using their own extension schemas and would not be
> claiming them to be UBL compliant since they aren't trying to be
> standalone UBL instances.
>
> I'm appreciating this discourse, Fraser ... thanks.  And I hope I've
> convinced TC members who are listening about what to use for the
> syntax of the extension element (you there Mike G.?).
>
> . . . . . . . . . . . . Ken
>
> --
> 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:  Varo, Denmark 2006-09-25/10-05
> 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]