Tim pointed out old rule/words that disappeared
before final release of NDR v1.0: "If the representation term is “Text”, it must be removed.
If the representation term is “Identifier”, it must be replaced with
“ID”.
So, all we need to do is add something like
"All duplication of words resulting from duplicate property
terms and representation terms, must be
removed."
That should give GEFEG what they need;
correct?
Thank
You,
Mike
At today's Pacific call we had a discussion about the rules for
truncating names. This lead from a request by GEFEG (the builders of the
software that we use to create schemas) to specify where we get naming rules
from. We need to conclude this issue immediately so we can update the
NDRs and get the 2.0 schemas built.
My research has brought me to the
following position. I am not aware of any other rules (either in CCTS or
UBL NDRs) that affect naming. If anyone knows then please add to this
set so we can get our NDRs updated this week.
Firstly, the initial name
for any BIE (information item) is the Dictionary Entry Name (DEN). The
UBLName is then based on this DEN. The DEN is the responsibility of the
ebXML CCTS and the UBLName is the responsibility of the UBL NDRs.
Details of these rules are given below. I will focus on Basic and
Association BIEs as the naming of Aggregate BIEs appears not the be the issue
and describing them would only add complexity to an already complex
issue.
All Dictionary Entry Names (DEN) are specified by following the
ebXML CCTS (v2.01).
For Basic BIEs this is initially as Rule
B24... "The Dictionary Entry Name of a Basic Business Information Entity
shall consist of the following components in the specified order: * the
Object Class Term of the corresponding Basic Core Component, and possibly
additional Qualifier Term(s), * the Property Term of the corresponding
Basic Core Component, and possibly additional Qualifier Term(s), * the
Representation Term of the Data Type on which the corresponding Basic Business
Information Entity Property is based."
So the initial DEN for
identifying a Contact might be 'Contact. Identifier. Identifier'
For
Association BIEs there is a similar Rule B25... "The Dictionary Entry Name
of an Association Business Information Entity shall consist of the following
components in the specified order: * the Object Class Term of the
corresponding Association Core Component, and possibly additional Qualifier
Term(s), * the Property Term of the corresponding Association Core
Component, and possibly additional Qualifier Term(s), * the Object Class
Term of the Association Business Information Entity on which the corresponding
Association Business Information Entity Property is based."
So the
initial DEN for other communcation channels associated with a Contact be
'Contact. Other_ Communication. Communication'
These DENs are then
refined using Rule B29... "For Basic and Association Business Information
Entities, if the Property Term is equal to the third component of the
Dictionary Entry Name, and the Property Term is not qualified, the Property
Term shall be removed from the Dictionary Entry Name."
So the DEN for
identifying a Contact would then be 'Contact. Identifier'. But the DEN
for any other communications associated with a Contact is not shortened,
because it is qualified by "Other_ ". So it remains 'Contact. Other_
Communication. Communication'. If it were not qualified it would have
become 'Contact. Communication'
As far as I can see, these are the only
rules for shortening Dictionary Entry Names.
There are no UBL
NDR rules about forming Dictionary Entry Names. Our NDRs state, "Since UBL is
an implementation of CCTS, UBL uses CCTS dictionary entry names as the basis
for UBL XML schema construct names. UBL converts these
ccts:DictionaryEntryNames into UBL XML schema construct names using strict
transformation rules." We have rule GNR2 that says, "UBL XML element and
type names MUST be consistently derived from CCTS conformant dictionary entry
names." Elements names are what we also know as the UBLName. These rules
for consistent derivations of CCTS conformant dictionary entry names are what
we have in the UBL NDRs.
Rule CTN 2 states: "A UBL
xsd:complexType name based on a ccts:BasicBusinessInformationEntityProperty
MUST be the ccts:Dictionary EntryName shared property term and its qualifiers
and representation term of the ccts:BasicBusinessInformationEntity, with the
separators removed and with the “Type” suffix appended after the
representation term." So the complexType name for identifying a
Contact would then be 'IdentifierType'
Then ELN2 adds: "A UBL global
element name based on an unqualified ccts:BBIEProperty MUST be the same as the
name of the corresponding xsd:complexType to which it is bound, with the word
“Type” removed."
So the element name for identifying a Contact would
then be 'Identifier'. A convoluted way of saying it, but it works!
For Association BIEs, rule ELN 3 states: "A UBL global element name
based on a qualified ccts:ASBIE MUST be the ccts:ASBIE dictionary entry name
property term and its qualifiers; and the object class term and qualifiers of
its associated ccts:ABIE. All ccts:DictionaryEntryName separators MUST be
removed. Redundant words in the ccts:ASBIE property term or its qualifiers and
the associated ccts:ABIE object class term or its qualifiers MUST be
dropped." NB I suspect that the first use of 'qualified' is not what was
meant. All ASBIEs follow this rule regardless of their qualification.
Otherwise we have no rule for ASBIE element names!
Following this
rule means the element name for the other communcations associated with a
Contact becomes "OtherCommunciation".
However, we aren't finished
because there are some UBL truncation rules for UBLNames. These
are...
"Each Basic BIE Property results in an element in the XML
Schema. The tag name is derived like this: <Basic BIE Property Property
Term>( ( <BBIE Object Class Term> != “Text” && <Basic BIE
Property Property Term> != <BBIE Object Class Term>) ? (<BBIE
Object Class Term> == “Identifier” ? “ID” : <BBIE Object Class
Term>) So the tag name is the name of the Basic BIE Property followed by
the name of the pertinent BBIE. If the BBIE is named “Text” or if the name of
the Basic BIE Property is the same as the name of the BBIE then it must be
elided. If the BBIE Object Class Term is Identifier then it is translated to
“ID” in the tag name. Here are some examples: "
Basic BIE Property Property Term |
BBIE Object Class Term |
Tag name |
Purpose |
Code |
PurposeCode |
Name |
Text |
Name |
Party |
Identifier |
PartyID | also,
described as... "If the representation term is “Text”, it must be removed.
If the representation term is “Identifier”, it must be replaced with
“ID”. Examples: Person. Name. Text becomes Name, Person. Residence. Address
becomes ResidenceAddress, and Address. Country. Identifier becomes CountryID.
"
NB. This rule is taken from the UBL NDR Working Draft 22, 18
February 2003 (wd-ublndrsc-ndrdoc-22 ) currently posted at http://www.oasis-open.org/apps/org/workgroup/ubl/ubl-ndrsc/document.php?document_id=1380.
This rule never made it to the NDR 1.0 but we made no decision to remove it
and have been following it regardless. I propose it be reworded (eg
Object Class Term should have been Representation Term) , update the examples
and then have it re-instated.
To summarize, if we use some of
elements from the structure called "Contact" in UBL 2.0, it has examples of
most of these rules.
BBIE DEN = "Contact. Identifier. Identifer"
shortens to "Contact. Identifier", gives UBLName = "ID" BBIE DEN =
"Contact. Name. Name" shortens to "Contact. Name", gives UBLName =
"Name" BBIE DEN = "Contact. Telephone. Text" does not shorten, gives
UBLName = "Telephone" ASBIE DEN = "Contact. Other_ Communication.
Communication" does not shorten, gives UBLName =
"OtherCommunication"
--
regards
tim mcgrath
phone: +618 93352228
postal: po box 1289 fremantle western australia 6160
web: http://www.portcomm.com.au/tmcgrath
|