Title: Message
I
trust, Gunther, that you generated that schema solely as an exercise for
illustration purposes. We are not at this stage contemplating throwing out
the window, our truncation rules, are we? We demonstrated over the past
two days that the truncation rules work almost flawlessly. Only one name
clash was uncovered and that has already been addressed (per last night's LCSC
call right?).
-Bill
-----Original Message-----
From: Stuhec, Gunther
[mailto:]
Sent: Thursday, January 16, 2003
2:13 PM
To: 'CRAWFORD, Mark'; ;
Subject: RE: [ubl-ndrsc] RE:
[ubl-lcsc] Global versus Local
Hello all,
I
generated a xml-schema with fully qualified global elements. That means, all
element names corresponds to the complete dictionary entry name of each BIE.
Is this the output, which we defined with fully qualified global
elements?
Kind
regards,
Gunther
-----Original Message-----
From: CRAWFORD, Mark
[mailto:]
Sent: Donnerstag, 16. Januar 2003
19: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.
