MHonArc v2.5.0b2 -->
ubl message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [ubl] Rules for Names (Dictionary Entry Names and UBLNames) -urgent action required.
From: Grimley Michael J NPRI <>
To: Tim McGrath <>,Grimley Michael J NPRI <>
Date: Tue, 27 Jun 2006 10:09:12 -0400
> the rule about duplicates is already
there.
I'm confused (which is not an uncommon state for
me).
The issue raised by GEFEG on the Atlantic call was
that there was no rule for the removal of duplicate
terms.
From: Tim McGrath
[mailto:]
Sent: Tuesday, 27 June 2006
0940
To: Grimley Michael J NPRI
Cc:
Subject: Re: [ubl] Rules for Names
(Dictionary Entry Names and UBLNames) - urgent action
required.
sorry i seem to have missed the mark. this isn't what i thought i
said. ther isn't really a connection between your statement and
your conclusion. the rule about duplicates is already there. what
we need is a statement about removal of "Text" and the shortening of
"Identifier" to "ID". These have nothing to do with duplication.
In other words, put back the words that disappeared before NDR
1.0
Grimley Michael J NPRI wrote:
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
From: Tim McGrath [mailto:]
Sent: Tuesday, 27 June 2006 0058
To:
Subject:
[ubl] Rules for Names (Dictionary Entry Names and UBLNames) - urgent
action required.
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
