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

MHonArc v2.5.0b2 -->
















ubl message






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

--

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








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




From: "Stuhec, Gunther" <>
To: "''" <>, ,       
Date: Tue, 22 Jun 2004 10:28:13 +0200






Title: Nachricht



Hello 
all,
 
I made 
a mistake in my starting text. I'm totally not in favor with some major 
modifications of the CCT-Schemas.
 
Kind 
regards,
 
    Gunther

  
  -----Urspr�ngliche Nachricht-----
Von:  
  [mailto:]
Gesendet: Montag, 21. Juni 2004 
  13:58
An: ; 
  
Betreff: [ubl] FW: [ubl-comment] 
  Comments to Tim's paper 
  (draft-mcgrath-UBLandCCTSschemas-0p1.sxw)


  
  Folks,
   
  Gunther has submitted this in response to 
  the paper put out by Tim.  In my opinion this also constitutes a set of 
  comments for release 1.0 as well and I would like us to ensure we add them to 
  the issues list and respond accordingly.
   
  Mark
  

  
  From: Stuhec, Gunther 
  [mailto:]
Sent: Mon 6/21/2004 7:44 
  AM
To: ''
Subject: 
  [ubl-comment] Comments to Tim's paper 
  (draft-mcgrath-UBLandCCTSschemas-0p1.sxw)


  
  Hello all, 
  I reviewed the paper from Tim (draft-mcgrath-UBLandCCTSschemas-0p1.sxw) and I'm 
  completely in favor with some major modifications of the CCT-Schemas. 
  
  We decided in the UBL NDRSC that we define XML 
  schemes from BIEs as efficient as possible. That means, it is not necessary to 
  create exactly the same construction as described in the CCTS V2.01, because 
  you can express many definitions of CCTS more effectively, if you're using all 
  XML Schema conventions.

  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.)
  Codes and Identifiers not using 
  xsd:normalizedString
=======================================
I have no problem with "xsd:normalizedString". 
  But I'm still recommending that a restriction 
  from "xsd:normalizedString" to "xsd:token" should be allowed for qualified 
  data types, because for some Codes and Identifiers, it must be necessary to 
  express these based on the built-in data type "xsd:token".
  Attributes for Codes and Identifiers
==========================
It is not necessary to do a declaration of attributes for 
  the supplementary components of codes and identifiers. Because these 
  supplementary components will be expressed by namespace and 
  annotation.
  Schema Modules renamed
====================
The names of the modules are 
  different to the UN/CEFACT ATG module names. 

  Alignent with OASIS
===============
1.) Naming of 
  Supplementary Components as attributes.
----------------------------------------------------------------------------------
I hope that OASIS still using the shorter 
  attribute names (without same terms of the Object Class and CCTs). 
  2.) Use of XSD normalizedString for code, 
  identifier and text components.
----------------------------------------------------------------------------------
See my comments to Codes and Identifiers 
  
  3.) Use of XSD built-in dataypes requiring the 
  "format" Supplementary Component
----------------------------------------------------------------------------------
I guess, it make no sense to define the attribute 
  "format" for unqualified data types. 
  Garret made the suggestion at one time, to separate 
  the CCT-module and the unqualified data type module, completely. The CCT 
  module should only be used for informative reasons and the unqualified data 
  type module should be the basis for all qualified data types and BBIEs. The 
  unqualified data type should be defined as efficient as possible and without 
  unnecessary attributes, like "format". I guess, this will be the best 
  way.
  4.) Restrictions on Binary Object for Graphic, 
  Picture, Sound and Video data type.
----------------------------------------------------------------------------------
We used all supplementary components for Binary 
  Object Type since the beginning. We should furthermore use all these 
  supplementary components as attributes for all types (Binary Object for 
  Graphic, Picture, Sound and Video). Because all supplementary components are 
  necessary for an unambiguous and standardized representation of binary 
  objects.
  5.) Patterns for Indicator data type.
----------------------------------------------------------------------------------
I'm agree. 
  Annotations
----------------------------------------------------------------------------------
The annotations of UBL library do not based on the 
  guidelines of the UBL Naming and Design-Rules (wd-ublndrsc-ndrdoc-V1pt0Draftp.doc). Therefore, there is a difference 
  between UBL LCSC, UBL NDRSC and OAG.
  Name of Representation Terms schema
----------------------------------------------------------------------------------
The UN/CEFACT using "unqualified data types". I 
  guess, this name is the most compliant one to the CCTS. 
  Abbreviation for Identifier (ID vs. Id)
----------------------------------------------------------------------------------
I prefer "ID" 
  Representing prohibited attributes
----------------------------------------------------------------------------------
If we're following the suggestion of Garret 
  (see. 3.) Use of XSD built-in dataypes ....), 
  than no prohibition of attributes is necessary, any more.
  I know, I'm a little bit late with my comments. 
  But I hope you'll still recognize my comments. Thank you. 
  Kind regards, 
          Gunther To unsubscribe from this mailing list (and be 
  removed from the roster of the OASIS TC), go to 
  http://www.oasis-open.org/apps/org/workgroup/ubl/members/leave_workgroup.php. 






Follow-Ups:

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








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

--

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