RE: [ubl-ndrsc] Extensions position paper draft

[Matthew Gertner <matthew.gertner@schemantix.com>]

Title: RE: [ubl-ndrsc] Extensions position paper draft

Sounds reasonable to me. Maybe we want to split the document up somehow and divvy the work out to the two SCs. I think we have enough to do in the CM SC to keep busy for two weeks while we await a decision on this.

 

Matt

-----Original Message-----
From: McKay, Dale R. [mailto:DMCKAY@logicon.com]
Sent: Thursday, December 06, 2001 7:17 PM
To: ubl-ndrsc@lists.oasis-open.org
Subject: RE: [ubl-ndrsc] Extensions position paper draft

Let's make the telephone meeting on December 19, already devoted to "extension", a joint meeting of the two committees. We can settle this (hopefully in .LE. 0 minutes) and move on to discussing the technical issue.

-----Original Message-----
From: Gregory, Arofan [mailto:arofan.gregory@commerceone.com]
Sent: Thursday, December 06, 2001 10:14 AM
To: 'Matthew Gertner'; ubl-ndrsc@lists.oasis-open.org
Subject: RE: [ubl-ndrsc] Extensions position paper draft

Matt:

 

I'm a little concerned that we get concensus from the design team on this, since it drives so many other decisions about modularity, which features of schema are to be used, namespaces & versioning, etc. I think we have too many teams working on the same thing at the same time to be splitting work up in an uncoordinated fashion, so we need to be really careful to stay aligned, even with the overlap in membership. Perhaps after the discussion next week - assuming we get agreement within the design team - we could then pass it off, but I do think we want to be careful about this.

 

Cheers,

 

Arofan

 

 

-----Original Message-----
From: Matthew Gertner [mailto:matthew.gertner@schemantix.com]
Sent: Thursday, December 06, 2001 10:04 AM
To: ubl-ndrsc@lists.oasis-open.org
Subject: RE: [ubl-ndrsc] Extensions position paper draft

As resolved in our CM SC conference call, we would like to suggest taking over work on the extensions position paper from the NDR SC, for two reasons:

 

(1) The CM SC has significant dependencies on this work and

(2) The CM SC has more bandwidth to devote to this at present, as our scope is more limited, and we are less on the critical path.

 

Note, of course, that all CM SC members are also NDR SC members, so this is purely an organizational step. Perhaps this could be raised on the next conference call.

 

Cheers,

Matt

-----Original Message-----
From: Gregory, Arofan [mailto:arofan.gregory@commerceone.com]
Sent: Tuesday, December 04, 2001 11:20 PM
To: 'Matthew Gertner'; Gregory, Arofan; Maler, Eve; ubl-ndrsc@lists.oasis-open.org
Subject: RE: [ubl-ndrsc] Extensions position paper draft

Matt:

Responses below... (indicated with **)

-----Original Message-----
From: Matthew Gertner [mailto:matthew.gertner@schemantix.com]
Sent: Tuesday, December 04, 2001 7:06 AM
To: 'Gregory, Arofan'; Maler, Eve; ubl-ndrsc@lists.oasis-open.org
Subject: RE: [ubl-ndrsc] Extensions position paper draft

First some random comments and questions, with the standard disclaimer that
these are just my naive opinions and should be bashed at will:

- Do I understand correctly that we are foregoing assembly rules entirely
and simply authoring schemas to model BIEs and business documents? I think
this is what is stated in section 2.2.2, but the discussion is a little
abstract.

**

I am of the opinion that we *do* need assembly rules, but that the initial job should be to define the core schemas. The hard requirement is that people have a mechanism to write their own docs with UBL components, which requires an act of assembly. For our own use, we could define the docs and then write the matching assembly rules after-the-fact.

**

- Section 3.1 implies that xCBL has some mechanism for subsetting, which I
don't think it does. I am correct that subsetting in xCBL is more a question
of an informal agreement between trading partners as to which of the many
optional elements in various xCBL element types are actually used?

**

Subsets exist as documentation (a big stack of XPaths) and as Schematron instances (a big stack of XPaths with some tags around them). Not yet well-supported by C1.

**

- In terms of ebXML (section 3.2): I have seen some discussion lately to the
effect that leveraging ebXML for marketing purposes is not an entirely
straightforward decision, since there is some feeling that ebXML is not
perceived as an unambiguous success in terms of fulfilling its stated goals.
We might find that stressing our tight links to ebXML has a rather negative
effect, at least in some circles. From a purely pragmatic perspective,
informal use of ebXML's valuable but very preliminary work on core
components might be preferable to trying to enforce a formal link to this
work. Not sure what the implications of the UBL charter might be in this
regard.

**

Political suicide not to be in some viable way ebXML-compliant. Maybe not such good marketing, but I think you'll find that UBL becomes the ebXML success story if we do our job right.

**

- Also on section 3.2: total agreement that the assembly rules, as defined
in ebXML, were not a good techical idea and had more to due with political
considerations. Furthermore, UBL is a big technical challenge from many
perspectives. If we want to succeed, we will have to make some compromises
in terms of repecting sensibilities, and we should be prepared to do so.

** Do I take it that you are proposing offending sensibilities? Hear, hear!

- I don't understand point (3) in section 3.3. What exactly is meant by OO
scoping? How does this jibe with the preliminary but (IMO) very sound
decision to restrict local element declarations to simple types or renaming
of types in a given scope (i.e. the BuyerParty case).

**

I think this is in agreement with that decision.

**

- What is the advantage of linking our syntactic specifications to some
formal semantic model? The whole discussion seems to imply that core
components and BIEs will be defined first as an abstract semantic model and
then "serialized" into UBL syntax. While this sounds sensible from a formal
perspective, I have a hard time seeing what is really gained by this, rather
than simply defining core components and BIEs as element types and schemas
and then documenting their semantics. Is this another ebXML-related
political decision?

**

No - this is good politics, but it has a lot of practical uses as well, especially going cross-syntax, and automating mappings and the like. Plus - and this is political again - all of our business expertise is coming from standards groups who were all behind core components, but who mostly didn't like UBL. Core components represents our best way to gather the expertise in these groups, and to get their needed support.

**

More generally, the only strong conclusions of this document appear to be:
(1) We need a mixed metholodogy combining extension and restriction.
(2) There are a host of open issues and it's still far from clear how we are
going to leverage the innate features of XML schema (in whatever
incarnation) to achieve interoperability.

** Yes, that's pretty much it. I wrote it to raise issues rather than to supply a solution, since there needs to be a lot more discussion here before a solution is identified.

**

I actually think that XSD does what we want, namely the possibility to
define BIEs with a "grab bag" of optional element types a la xCBL, and the
ability to specify in a concrete implementation (using restriction) which
optional elements remain optional, which become required and which become
not allowed. XSD should be sufficient for this. It might be nice to have an
& connector like in SGML (I guess RELAX NG calls this "interleave"), but I
don't know enough about the business case to know how important this is. If
we take the xCBL grab bag approach, are business people going to care if the
order of the optional elements is imposed?

There is also a big bug in that XSD doesn't let us define code lists as
enumerations and then extend and restrict them.

My conclusions:

(1) XSD is probably okay for our purposes. We NEED restriction. Rather than
trying to work around this, we should be prepared to lobby hard to get
consistent tool vendor support for this. The real flaw with XSD is its
complexity, but this could be mitigated by defining a clean subset (i.e. one
of the major goals of this SC). The code list bug is unfortunate but I don't
see any solution other than kludgy ones. I've heard a lot of grumbling about
XSD; does this accurate represent the reasons for people's unhappiness, or
are there other technical issues that I am missing?

(2) There is another alternative but it might be a bit loopy. This would be
to work with the RELAX NG group to define an extension mechanism informed by
our context methology work that meets all of our requirements in a clean
way. The advantages would be that: (a) We get to use RELAX NG which is
frankly much cleaner than XSD and (b) We get to define an extension
mechanism specifically to meet the needs of the business world, which XSD
tried to do but, in a vacuum (i.e. without the prior existence of ebXML and
UBL context metholodgy work), did not entirely succeed at. We would then
define a mapping to XSD that supports various subsets of XSD functionality
(specifically with or without restriction support) but recommend that people
use RELAX NG in order to exploit the full power of UBL. I'm pretty sure that
this will be labelled as both politically and technically unfeasible (to
what extent is RELAX NG so clean because it DOESN'T have an extension
mechanism?), but is anyone brave enough to stick their neck out and support
this idea?

One last point: I didn't crosspost to the CMSC list, although this is
extremely relevant to our work, because I believe that all members are also
members of this SC. If anyone is in the CMSC but not in the NDRSC and
therefore didn't receive this mail, please let me know. :-)

Cheers,
Matt

** Matt: I don't think Relax-NG does everything we need, especially around typing, but I wouldn't be surprised to find out that I am wrong. The UBL group has decided to go with XSD, and yes, I think it does what we need assuming we can get vendor support for features like restriction.  I agree we should get proactive on this point. It just makes everything ugly, verbose, and complex, which is the main reason I hate working with it, but I didn't see any option for the purposes of this paper, given decisions made by the group.

Cheers,

Arofan
**

> -----Original Message-----
> From: Gregory, Arofan [mailto:arofan.gregory@commerceone.com]
> Sent: Tuesday, November 27, 2001 9:41 PM
> To: Maler, Eve; ubl-ndrsc@lists.oasis-open.org
> Subject: RE: [ubl-ndrsc] Extensions position paper draft
>
>
>
> Folks:
>
> Here is a *very* rough draft of the position paper (late, but
> you know how
> all that L-Tryptophan slows you down...)
>
> I've tried to capture my thinking as best I can, but it is in somewhat
> abbreviated form, and could be organized more clearly. Please
> forgive my
> inelegancies here. Hopefully, it will serve as the basis of a
> discussion, or
> further discovery work.
>
> Cheers,
>
> Arofan
>
>