[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]