Bill:
This is a spurious challenge, Sir, and not only because it comes from you...
;-) Besides, it is counter to our design goals (which call for optimizing
for XML technology). I can name a customer of my past employers who, for
contractual reasons (tiered pricing, to be exact) needed to process mammoth
POs (megs of text, literally), since they got discounts on the quantities in
a *single* order. Performance *is* an issue for large enterprises (as well
as third-party service providers), because they have large volumes of
throuigh-put, and are as cost-sensitive on their own scale as anybody.
Besides which, we NEVER made a decision about this in NDR. We discussed the
containership issue, and agreed to not discuss it further until we had
something real in hand to base discussion on. I have not raised the issue
since. I am raising it now, because we never finished that discussion.
I must say that I found the arguments for having an too-flat XML structure
far from compelling.
I am not re-iterating the many arguments I could make for a reasonable depth
of nesting in XML structures - these are self-evident, and have been raised
before. What I am doing is trying to point out specific reasons that the
current design could benefit from a greater degree of containership.
I would have thought you, as someone who is generally keen on encapsulation,
would agree with me...
(Hmmm - XML-to-Java binding, there's another problem we hadn't raised. But I
don't suppose anybody will be processing XML with Java bindings, especially
since the only tools that deal with this are things like XML Spy and JAXB...
;-))
The issue before was focused on data modelling, and my arguments are not -
our object structures in terms of the business model are fine, from the
perspective of the modeller. What they are not good for is someone who has
to work with a sub-optimized XML output, derived from the business model, in
an implementation.
To quote you: "Bentley says: premature optimization is the root of all
evil." I would argue that what we are doing currently is a serious break
from the norm among existing e-Commerce XML libraries, because it is so
shallow. Thus, our current release is a premature optimization for something
no one has even expressed in terms of the technology. (Actually, depth of
nesting in SGML and XML structures is a known quantity to the people who
have been working with this stuff for the past 10+ years, and UBL in op70
is, in my experience anyway, a departure from the norm.)
My point is, that there is more to be discussed here, and it will be greatly
facilitated by having real schemas and instances in hand. At the very least,
I'd like for the group to make a real decision about this based on an
examination of the existing release. I am not proposing that we argue this
with LCSC, since the binding between the models and the XML output is in
NDR's scope, not theirs. But we do need to take a look at how tools will
process the stuff, and whether we really have the best design.
Cheers,
Arofan