OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: AW: Review and comments of OASIS Universal Business Language (UBL) V1.0


Hello Jon,

I sent the following message to tim a end of june.
Further comments will follow, today.

Kind regards,

	Gunther

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



Hello Tim,

>> i did wonder about the initial comment. ;-) 

I would like to say that I'm disagree with some major modifications of the CCT-Schemas.. I hope I found the right words.

To your comment. I guess, we should always define rules for definition of schemas in the most efficient way. I makes no sense to transfer all UN/CEFACT CCTS conventions directly into the UBL XML schemas, because many information are redundant and therefore not really necessary for implementation. I mean with this the representation of supplementary components, especially. Therefore, it is recommended to truncate all Object Class Terms from the Supplementary Components, which are represented as attributes. Because, you already have this information in the element name and we're also 100% compliant to the CCTS. I'm so sorry that I made a mistake in some attributes. Therefore, you'll get the correct names of attributes, now:

AmountType
    currencyID
    currencyCodeListVersionID

BinaryObjectType
    format
    mimeCode
    EncodingCode
    CharacterSetCode
    uRI
    Filename

CodeType
    listID
    listName
    listAgencyID
    listAgencyName
    listVersionID
    listURI
    listSchemeURI

IdentifierType
    schemeID
    schemeName
    schemeAgencyID
    schemeAgencyName
    schemeVersionID
    schemeDataURI
    schemeURI

MeasureType
    unitCode
    unitCodeListVersionID

Quantity
    unitCode
    unitCodeListId
    unitCodeListAgencyID
    unitCodeListAgencyName


If you do not allow this type of truncation, than we have to change many other things to be compliant to the CCTS. For example, every type must have all supplementary components

Kind regards, 

    Gunther


-----Ursprüngliche Nachricht-----
Von: Tim McGrath [mailto:tmcgrath@portcomm.com.au] 
Gesendet: Mittwoch, 23. Juni 2004 05:46
An: Stuhec, Gunther
Cc: ubl@lists.oasis-open.org; ubl-dev@lists.oasis-open.org
Betreff: Re: [ubl-dev] AW: [ubl] FW: [ubl-comment] Comments to Tim's paper (draft-mcgrat h-UBLandCCTSschemas-0p1.sxw)


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



-----Ursprüngliche Nachricht-----
Von: jon.bosak@sun.com [mailto:jon.bosak@sun.com] 
Gesendet: Donnerstag, 22. Juli 2004 01:22
An: Stuhec, Gunther
Cc: ubl@lists.oasis-open.org; Von Riegen, Claus
Betreff: Re: Review and comments of OASIS Universal Business Language (UBL) V1.0


Hello Gunther,

The UBL TC is processing the last of the comments received on the
UBL 1.0 Committee Draft before submitting a revised version to
OASIS.  We agreed earlier to consider your comments of 18 June
even though they came in after the close of the review period, but
in attempting to resolve these issues in today's Atlantic TC call,
we found that we were lacking enough detail to address them
satisfactorily.

We suspect that most of your comments have to do with differences
between UBL 1.0 CD and an old version of the NDR document and that
they are therefore no longer relevant, as noted in a message sent
to you from Tim McGrath 23 June 2004 and archived at

   http://lists.oasis-open.org/archives/ubl/200406/msg00090.html

However, in the absence of any response from you to the message
from Tim, we cannot be certain that these issues are no longer
applicable without knowing further details.  In order to consider
your comments effectively, therefore, the TC has asked me to
request that you review the issues you have raised in light of the
NDR checklist used in UBL 1.0 CD (rather than an older version of
the NDR document) and to resubmit those issues together with
specific examples that will enable us to understand them in enough
detail to resolve them.  Tim included a copy of the 1.0 CD
checklist in the message referenced above.

Since we are just a few days away from resolution of the remaining
issues and are striving to complete the CD revision before leaving
for our meeting in Copenhagen, the TC has asked me to request your
clarification of the issues via posting to the UBL TC mail list no
later than this Friday, 23 July.  This will allow us to review
your issues in email in time to finish resolution of 1.0 CD issues
in our Atlantic and Pacific TC meetings 28 and 29 July.

Some other members of the TC will be attempting in the meantime to
review your issues against the 1.0 checklist as well, but we all
consider your input very valuable and want to have the benefit of
clarifications to your earlier comments if it is possible to
receive them in time for consideration during this review cycle.

Best regards,

Jon


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]