Title: 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.
