RE: [ubl-ndrsc] Containers (long)

MHonArc v2.5.0b2 -->

ubl-ndrsc message

[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [List Home]

Subject: RE: [ubl-ndrsc] Containers (long)

From: "A Gregory" <>

To: <>,<>

Date: Tue, 9 Sep 2003 02:52:46 -0700

Jon:

I am afraid I may not be able to join the next call in which these
issues are discussed, but I wanted to express my views on this important
issue at this point. 

I support your proposal (despite feeling that the lack of
containerization will prove to be a barrier to adoption of our schemas).
It is not worth further discussion, and, as you state, we can always fix
it in revision should implementation prove to us the need for more
containers.

I guess my concern is this: we have a clear view (especially in LCSC) of
a model and methodology that is focused on semantic completeness, and -
as a direct bi-product of our focus on that model - we prefer a
one-to-one correspondence between the model's semantic constructs and
the syntactic constructs in the XML. Hence, no containers.

I guess I believe that this is putting the cart in front of the donkey.
I always believed that UBL's first order of business - their primary
deliverable, if you will - was a set of schemas that were easy to use,
easy to extend, and got the job done. The modeling methodology was a
secondary deliverable, existing in support of XML schemas themselves,
helping us produce complete and understandable schemas. We already have
a "syntax-neutral" methodology from ebXML Core Components, and UBL's
focus was supposed to be different - on the XML itself. I'm not sure we
have maintained this focus sufficiently.

I fully appreciate that we have helped clarify the virtues and failings
of the ebXML CC methodology in producing the UBL library. However, I
feel that our modeling methodology is too complex for general use - it
took us quite a while to understand it internally, and - powerful (and
even fascinating) as it is - I believe that the majority of our users
will not bother with it. They will simply take our schemas and use them.

Containerization may or may not produce efficiency gains in processing:
this remains to my mind an open issue until someone does some very
comprehensive tests, which we have not, and will not do within the
necessary timeframe.

Questions about ease-of-use and comprehensibility remain, however. I
believe that containers contribute materially to these things in a world
where most developers won't be working from our semantic model, but from
the XML schemas. (This is also a major point in the local-versus-global
debate. Local is, pure and simply, harder to master. There's a good
quote on this point from Eric van der Vlist in his "XML Schema" book
from O'Reilly, page 20, last paragraph, first edition.)

A few examples, taken from our discussions: (1) Containers are not
absolutely necessary for writing presentational code, but they make it
easier, especially for the unsophisticated. (2) Similarly, containers
provide a degree of encapsulation that makes code reuse easier, and
makes the XML easier to understand. Not absolutely necessary, but nice
to have. (3) Tools *can* present XML documents without having containers
to give "collapsible" file/folder views, but it's awfully nice to be
able to collapse the bits you aren't focused on at the moment. We need
containers for this. (It helps to remember that most developers aren't
concerned only with semantics, but also with the syntactic constructs
with which the code directly deals. They care about the semantics, but
they also care about how the syntax constructs are packaged.)

These are the kinds of minor optimizations to our XML formats that we
have traded for a greater degree of consistency with our semantic model.
I think this is a poor trade-off. It makes life easier for us (in
creating and maintaining our library), but not for our users.  

Again, I agree that we should go with the status quo for now: we can fix
this in revisions if it proves to be a major problem, as has happened
for some other e-business vocabularies. And I'm not completely satisfied
with the proposed containership rules, either (although I do feel that
in this case the cure is in fact better than the disease.)

In the interests of completing a 1.0 version in a timely fashion,
however, I support withdrawing the existing containership rules.

Cheers,

Arofan