Re: [ubl-dev] Re: [xml-dev] Re: [ubl-dev] UBL 2.0 and Schema Extensibility

["Fraser Goffin" <goffinf@googlemail.com>]

> 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. 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. It is a 'black box' to everyone else since they won't have
'that' schema. They may of course be using their own. So this is
extensibility for non schema owners, in this case everyone other than
the UBL TC.

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.

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

Maybe your saying that the content model of the extension may itself
use constructs defined by UBL. But in that case wouldn't that violate
##other ?, and if you put it in your own namespace then really its n
ot UBL even if it looks remarkably similar and the intended semantics
are identical ?

Fraser.

On 16/05/06, G. Ken Holman <gkholman@cranesoftwrights.com> wrote:
> At 2006-05-16 17:25 +0100, Fraser Goffin wrote:
> >>It has been difficult to illustrate to people who genuinely believe
> >>that W3C Schema solves all problems that there are problems for which
> >>it is ideally suited and there are problems for which other
> >>technologies are absolutely required to be used in its place.
> >
> >I am *not* in this camp and neither are my immediate colleagues.
>
> Yes, I understand that and you have been supportive of exploring how
> layering can help.
>
> I understood the problem you were having was my problem of getting
> others to understand the need for layering, not that you were having
> the problems of understanding yourself.
>
> As I heard you describe your questions, I find I'm in the same boat
> of people asking me to provide pure W3C Schema solutions when I am
> unable to do so and have it work.
>
> >As you have said many times yourself Ken, structural validation is
> >sometimes a pre-requisite to other forms (e.g. schemaTron) that may be
> >used in addition, to cover those aspects that are not practically
> >possible using schema validation alone. I agree entirely.
> >...
> >So, back to my original point. It is *not* that I (or others)
> >necessarily think that validation by XSD alone will be sufficient,
>
> I know you don't but here are others who do and it is for that
> audience that we need help trying to get them to understand the role
> W3C Schema plays and the roles it does not play.
>
> >its
> >just that XSD *does* have a legitimate and useful role to play (even
> >if just limited to structural and some content validation) and I don't
> >want to deny that opportunity to anyone processing messages that are
> >specified by schema that I also subscribe too.
>
> And I agree XSD plays a critical role in the process and, indeed, all
> of the layers are dependent on a successful XSD pass of the instance.
>
> >So, setting processContents = 'lax' as a minimum allows those that
> >want to perform at least some level of validation on an otherwise
> >opaque part of the message without the need for implementing any other
> >checks if they don't want to.
>
> But what if a black-box use of a UBL construct violates UBL ...
> perhaps because the UBL construct has a required child, but that
> isn't needed by the black box that has wrapped its use of UBL in its
> own element (thus being a black box) and it is taking advantage of
> what it needs ... a "lax" validation would interfere with that.
>
> >For those that do have the inclination
> >to do more, they haven't lost anything and indeed as you said and now
> >I have repeated, the structural validation step may very well in some
> >cases be a required pre-step in order to remove the possibilitiy of
> >getting 'false positives'.
>
> I think a black box should be totally opaque ... if anyone doesn't
> need the extension then they surely don't need to look inside ...
> otherwise we might get "false negatives".
>
> >Many of the organisations that subscribe to the standards in my
> >industry sector are pretty small outfits with little or no IT support.
> >They use pre-configured packages that often provide little
> >sophistication for processing XML messages beyond the basics. Updating
> >these packages can be a costly exercise. So anything they can get 'for
> >free' is undoubtedly welcome.
>
> Indeed ... it has long been an objective to provide a rich
> out-of-the-box experience.
>
> . . . . . . . Ken
>
>
> ---------------------------------------------------------------------
> 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/
>
>