[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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. - 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? - 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. - 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. - 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). - 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? 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. 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 > -----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 > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC