If the problem is as described by Bill (fix of documentation bug resulting in wrong element names [wrong in the sense of "not intended"]) then I agree that the bug fix should be backed out. Burcham, Bill wrote: > 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 > > >