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)
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
-----Original Message-----
From: jon.bosak@sun.com [mailto:jon.bosak@sun.com]
Sent: Monday, September 08, 2003 9:08 PM
To: ubl-ndrsc@lists.oasis-open.org
Subject: [ubl-ndrsc] Containers
NDR SC members,
I am not a voting member of the NDR SC, but as a concerned
observer, I'd like to urge that you consider withdrawing the
current rule regarding list containers at your meeting on
Wednesday.
Let me be clear that I share the feeling that we need more
containerization rather than less. In fact, as I indicated during
the joint LC/NDR calls last week, the current example showing
multiple line items rattling around loose inside the invoice
document makes me very nervous. I believe on general principles
(*very* general principles) that this is going to cause problems
for processing applications farther down the line, and the
excellent position paper developed by LC on this subject has not
convinced me otherwise.
That paper has, however, convinced me (1) that the proposed cures
are worse than the disease and (2) that we don't understand the
potential problems well enough to propose a better solution at
this time. Furthermore, it appears that there are no currently
demonstrable performance consequences large enough to offset the
additional complication that would result from the generation of
list containers.
With regard to the proposal (which I believe was mine) to assign
LC the task of manually indicating list containers in the data
model, the reply that LC has already identified the semantically
meaningful containers seems to me a valid one. LC is saying, in
effect, that they have already containerized everything that made
sense to put into a container, and that if I'm bothered by the
sight of line items running around naked, then the onus is upon me
to provide a good semantic reason for categorizing the group as an
ABIE. And I don't have one.
I've listened pretty hard to the recent discussions on this point,
and my conclusion is that we will have to revisit this question in
some future major (non-backward-compatible) revision, but that we
don't undertand the problem well enough right now to design a
clearly appropriate solution. No one has questioned that the
schemas will work if they remain as they are now without the
application of the list container rule. Since it appears obvious
that the application of an automatic container generation rule
will significantly complicate the schemas, and since we cannot
show a clear benefit commensurate with this additional complexity,
I think (as an interested observer who cares about our time line)
that we should proceed without nonsemantic containerization until
experience can show us a better way.
Jon
To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/ubl-ndrsc/members/leave_wor
kgroup.php.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]