Re: [ubl-dev] AW: [ubl] FW: [ubl-comment] Comments to Tim's paper(draft-mcgrat h-UBLandCCTSschemas-0p1.sxw)

MHonArc v2.5.0b2 -->

















ubl message






[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [List Home]








Subject: Re: [ubl-dev] AW: [ubl] FW: [ubl-comment] Comments to Tim's paper(draft-mcgrat	h-UBLandCCTSschemas-0p1.sxw)




From: Tim McGrath <>
To: "Stuhec, Gunther" <>
Date: Wed, 23 Jun 2004 11:45:44 +0800










i did wonder about the initial comment.
;-) 


unfortunately I am unable to be in Waldorf to discuss this personally but
i want to make a few reactions to your comment on attribute naming.



  Formal Attribute Naming of Supplementary
   Components

  =========================================

  We decided in UBL NDRSC that we can truncate
the same names of "Object    Class Terms" of the supplementary components,
if we declare attributes of it.    Because these information will be already
expressed by the element tag name    and therefore they are redundant. You'll
find this rule [ATG1] in the document    the document "wd-ublndrsc-ndrdoc-V1pt0Draftp.doc".
  
   
  I'm agree that is a mistake in "AmountType".
The    correct attribute name of "Amount Currency. Code List Version. Identifier"
   must be "currencyCodeListVersionID", because the name "Currency" isn't
   expressed by the element tag name itself.
   
  If we would like to be formal with CCTS,
than we    should be in 100% compliant to CCTS on every part of the XML schemas.
(e.g we    have to use the Object Class Terms in tag names of every ABIEs,
BBIEs and    ASBIEs, we have to use all supplementary components like "Date
Time. Format.    Text", we should not allow to truncate "Text" etc.)

The NDR document rule (i assume you mean ATN1) does state that "Each CCT:SupplementaryComponent
xsd:attribute “name” MUST be the ccts:SupplementaryComponent dictionary entry
name property term and representation term, with the separators removed.".
 


But the examples in the NDR document (and in your previous CCT schemas) do
not follow that either.  they have things like...


<xsd:attribute name="unitCodeListID" type="xsd:token"  use="optional"/>
for Quantity Unit .Code List. Identifier


surely you agree that:


Object Class = Quantity Unit

Property Term = Code List

and

Representation Term = Identifier


So to follow ATN1 it should have been called "codeListID" not "unitCodeListID".
 This type of thing happens throughout your original CCTs schemas.


As you must have realized, the problem with ATN1 is that it would give us
synonymous attribute names and also ambiguous ones.  This is because the
Dictionary Entry Names often use Object Classes that are not the same as
the Object Class of the supplementary component itself..  As in the previous
example, the supplementary component "Quantity" uses properties from the
object classes "Quantity" and "Quantity Unit".


So we do need to enhance the attribute naming rule (ATN1) with additional
information.


You chose to extract part of the Object Class name to do this.  You took
the word "unit" from the Object class "Quantity Unit" and prefixed the attribute
name with it.  that is why we have "unitCodeListID" in the example above.
 It did resolve the issue.


The problem with this approach is that it is arbitrary and relies on always
having an object class name that this can work with.  in other words, it
is dependent on the object class name having two words- the first being the
same as the supplementary component name. i don't think this is reliable.
an example of this not working is when we come to the TextType we must give
the attribute name as "languageID" for the dictionary name of "Language.
Identifier".  In other words you do then use the object class as part of
the attribute name.


What i proposed is that we rationalize this so that we are consistent.  The
best i could  think of is that we use the ATN1 rule where is creates a semantically
meaningful and unique attribute name.  This means in cases where the object
class is the same as the supplementary component name.  In all other cases
we use the object class + property term + representation term to achieve
a consistent result.


-- 
regards
tim mcgrath
phone: +618 93352228  
postal: po box 1289   fremantle    western australia 6160