RE: [ubl] Rules for Names (Dictionary Entry Names and UBLNames) -urgent action required.

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 <>, 
Date: Tue, 27 Jun 2006 09:03:11 -0400









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