RE: [ubl-ndrsc] R13 contradiction

[Grimley Michael J NPRI <GrimleyMJ@Npt.NUWC.Navy.Mil>]

I agree with Bill. I believe the (relative) stability of the tag names is significantly more important than the documentation at this time.

At least in my circle, people are more interested in the naming and design rules, and the schema and tag names resulting from them, than they are in the documentation and use of IDs.

Thank You,
Michael Grimley

NUWC-NPT 





-----Original Message-----
From: Burcham, Bill [mailto:Bill_Burcham@stercomm.com]
Sent: Friday, 17 January 2003 11:40
To: 'Eve L. Maler'
Cc: ubl-ndrsc@lists.oasis-open.org; 'Tim McGrath'
Subject: RE: [ubl-ndrsc] R13 contradiction


Gosh you're absolutely right Eve!  I totally missed the "with the separators
and object class term removed"  Sorry about that Eve and group.  The rule
looks fine and it's perfectly clear that the object class term is (by
default) elided.

That being said, how does NDRSC feel about UBL going out the door with every
single tag name *including* the object class term?  That's what's about to
happen if no one says different.

Problem was that when the Perl scripts were upgraded to do "global elements"
a _documentation_ bug was introduced that caused the ID's for elements
representing Basic BIE Properties to be kind of messed up.  For each BIE,
all the Basic BIE Properties that referred to it got the same ID and
documementation annotation.  Note that for some reason this bug did not
affect the Ids on elements representing Association BIE Properties -- they
each got their own ID and documentation annotation just fine.  By changing
the Perl scripts to tack the object class term on the front of every single
element (in fact both those representing BBIEPs and ABIEPs) the
documentation problem disappeared.  But now, element names are long and
there is never any reuse of tag names across content models, e.g.:

	<xsd:complexType name="ReceivedTransportHandlingUnitDetailsType">
		<xsd:annotation>
			<xsd:documentation>
				<ccts:ABIE dictionaryEntryName="Received_
Transport Handling Unit. Details" definition="information about a set of
items which can be considered to be an undividable set of items for the
purposes of delivery, also know as a 'logistics unit'."
qualifierTermObjectClassTerm="Received" objectClassTerm="Transport Handling
Unit" qualifierTerm_PropertyTerm="" propertyTerm="Details"
representationTerm="Details" xmlns:ccts="CCTS.xsd"/>
			</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element ref="ReceivedTransportHandlingUnitID"/>
			<xsd:element
ref="ReceivedTransportHandlingUnitTypeCode"/>
			<xsd:element
ref="ReceivedTransportHandlingUnitHandlingUnitReceiptLine"
maxOccurs="unbounded"/>
		</xsd:sequence>
	</xsd:complexType>

I especially loathe "ReceivedTransportHandlingUnitHandlingUnitReceiptLine".

To me it seems better to release schemas with the documentation problem and
tag names that will be stable across releases, than to introduce unstable
tag names (they'll have to change back in the next release right?) just to
get the doc clean.

Now I understand that the documentation isn't "just" documentation -- that
in fact we envision sophisticated processing on those Ids.  But is that a
priority in this very first release?  Should that priority trump the
stability of our tag names?  My worst fear is that we release with these
long (non-reusable) tag names and then we're stuck with them forever.

Recall too that the action that triggered the Perl script changes in the
first place was a realization that a crucial NDR design decision was
violated and that we had to fix it (local versus global).  Now it seems we
are in danger of violating an equally crucial and hard-won decision (tag
naming).

-Bill