Title: Global versus Local
Greetings,
I agree
100% with the content and spirit of Mark's comments. I've been
concerned by the number of conversations/debates
that are based on the limitations of the tools we are using to
model and/or create the schemas and library components rather than simply on the
merits of the issue at hand.
Thank You,
Michael
Grimley
-----Original Message-----
From: CRAWFORD, Mark
[mailto:]
Sent: Thursday, 16 January 2003
13:31
To: ;
Subject: [ubl-ndrsc] RE: [ubl-lcsc]
Global versus Local
:
Fixed element names - All element tag names
are fixed. That means that we have two possibilites: 1.) We're declaring
global elements with very generic and short tag names (like in the
attached example). By that way, we will have one global element for many
BIEs with different semantic meanings. This will be not the right way,
because every BIE can have different characteristics and definitions. 2.)
Otherwise, we're generating unique tag names according the dictionary
entry names. That means that we will have huge tag names (exp.
DespatchedTransportHandlingUnitTypeCode). Or we need a logical rule for
generating shorter names.
[CRAWFORD, Mark] I don't
see 1 as being compliant with the NDR. We talked about this in
Burlington and Menlo Park. I don't see a problem with 2 as this is
what we are supposed to be about and I have been arguing for from the very
beginning. Remember, we all agreed that UBL was providing a business
vocabulary. That means fully qualified dictionary entry names for
all of our content. We developed our truncation rule only after
a great deal of discussion, and only after it was determined that we would
retain semantic clarity. We also discussed global vs. local at great
length, and arrived at a near unanimous agreement. I think we
should retain both. If we have to give up something, the first
to go should be the truncation capability as it is the least valuable to
human (read that SME) use. I would suggest however that a logical
rule can quite possibly be developed that would retain full semantic
clarity in conjunction with global
declarations. I would suggest that the rule
should be [xx] Element names MUST not be truncated in accordance with
rule xx, if such truncation creates duplicate element names within
the schema with different semantic meanings. in other words
-
The element
PaymentTermsDetails can be declared as PaymentTerms as long as
it is the only BIE with an Object Class of Payment and Property Term
of Terms. The element PaymentTermsDetails can not be declared
as PaymentTerms If the element PaymentTermsText also
occurs.
This
should be a simple add to the script
Logical rules for tag names missing - I said
it before. We need a logical rule for generating shorter tag names. But
this is very hard to do that, because we don't know, which kind of term we
can eliminate from each tag name. I thought, we defined the rule for
representation of tag-names of child elements. It says that, if the the
object class of the aggregation and the child BIE is the same, than we can
delete the object class from that BIE. That is very easy and
understandable and furthermore, it is automatically processable.
Furthermore, we defined some rules for deleting the words: "Details" and
"Text". By this, you'll get sometime the same tag names (exp.
PaymentTermsDetails and PaymentTermsText). What do you do with that
elements?
[CRAWFORD, Mark] see previous proposal.
It is not really compliant with ebXML CCTS -
If you using local elements, it will be very easy to distinguish between
CCs and BIEs. All complex types representing a ACC or BCC and can be used
as ASBIE or BBIE within an ABIE. The ACCs or BCCs do not have any
qualifiers, but the ASBIEs or BBIEs can have. If you using local elements,
which are based on a complex type, you can named this BIE according the
conventions of ebXML CCTS. Furthermore, the BIEs should be not reusable
any more, like the local element within an aggregation.
[CRAWFORD, Mark] I don't think I understand this. We
never represent CCs in an instance document. If we want to be
fully compliant, then lets forget completely about truncating names and
simply use the BIE name as the tag.
All namespaces will be in the tag-names, too -
If the global element prefixed by a namespace, you'll see the prefix in
the xml-instance, too.
[CRAWFORD, Mark] Whets
wrong with that?
The global elements will be not implemented in
some interfaces as well as software components - Some software vendors
have seen that local elements which based on complex types will have much
more advantages in reusability, short tag-names, modularity etc. These
software vendors are concentrating into this direction and do not plan
implementing any feature for handling global elements. [CRAWFORD, Mark] Sorry,
this is not a valid argument. I could as easily say that some
users have mandated the use of all global (i.e. U.S. government) and
will not use any standard that supports use of
local.
[CRAWFORD, Mark] In my opinion, we should never loose
sight of the fact that the spreadsheet is simply a convenience for doing
our work, and will not have a life after we deliver our products.
The real value is in the schemas and in the library
components. None of the aforementioned arguments in my mind
justify reversing our decision on
global.
