[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: FW: [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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]