[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Comments on the NDR document (wd-ublndrsc-ndrdoc-V1pt0Draftl)
Following my confusion about some of the terms used in your response about the UBL Logical Model, I have studied the latest NDR document, known as draft L (http://www.oasis-open.org/committees/download.php/4450/wd-ublndrsc-ndrdoc-V1pt0Draftl.pdf) to gain some background into where your questions and statements were coming from. I now have a better understanding of some of the issues that have become problematic for the NDR team. The attached comments and notes try to explain what I see as the differences in perspective. I apologise for copying such a long email to the entire UBL list, but given the overall UBL interest I think it better than sending to individuals or any specific group. I hope that this input will assist to both improve the NDR document and make it more consistent with the other UBL deliverables. -- regards tim mcgrath phone: +618 93352228 postal: po box 1289 fremantle western australia 6160
Line 28 (Cover page)
Eve Maler's name is misspelt.
Line 29-31 (Abstract)
The statement... "This specification documents the naming and design rules and guidelines for the construction of XML components from ebXML Core Components."
appears to have been changed from the more correct ...
"This specification documents the naming and design rules and guidelines for the construction of XML components for the UBL vocabulary."
This latter statement concurs with the current body of the Introduction (lines 180-181). The former belongs to ATG2. Was this chnage intentional?
Line 182 (section 1 Introduction)
The Charter of NDRSC is to "Recommend to the TC rules and guidelines for normative-form schema design, instance design, and markup naming, and write and maintain documentation of these rules and guidelines". This should go in here.
Line 189-190 (section 1.1 Audiences)
Given the charter above it is not "the UBL Library Content Subcommittee will use this document to create normative form schema for business transactions." it should be "the UBL TC rules and guidelines to create normative form schema for business transactions.". In fact, it is the Tools and Techniques SC who is the primary audience within UBL.
Line 190-193 (section 1.1 Audiences)
We say that "External developers will use this document to extend and restrict UBL schema in a fashion that will ensure conformance to the UBL design rules and guarantee compatibility with existing UBL schema." But we dont actually do this. Isn't that what the Context Methodology is all about?
Lines 200-203 (section 1.2 Scope)
The statement... "This specification conveys a normative set of XML schema design rules and naming conventions for the creation of business based XML schema for transactions being exchanged between two parties using objects developed in accordance with the ebXML Core Components Technical Specification."
should be more specific...
"This specification conveys a normative set of XML schema design rules and naming conventions for the creation of XML schema for business documents being exchanged between two parties using objects defined in accordance with the ebXML Core Components Technical Specification."
a. they are business documents not transacations
b. we dont develop according to CCTS, it is not a methodology. we use CCTS to define the things we develop.
Line 301-324 (section Design for Extensibility]
This section should really go in the main body of the UBL spec. it also oversimplifies the issue by assuming that extension and restriction are all the modifications necessary. it fails to address the need for changing rules as well as structure.
Line 326-327 (section 1.4.3 Tool Generation)
No need to specify number of generators (we now have three - but it should not matter how many).
Line 328-329 (section 1.4.3 Tool Generation)
The statement ... "In conformance with UBL guiding principle 3, the UBL design process has scrupulously avoided establishing any NDR that sub-optimize the XSD in favor of automatic generation." needs attention.
It is not the UBL design process that does this, it would be better to say ...
"In conformance with UBL guiding principle 3, the UBL NDRSC has scrupulously avoided establishing any rules that sub-optimize the XSD in favor of automatic generation."
Line 352- 354 (section 2. Relationships to ebXML)
The statement ... "UBL employs the methodology and model described in Core Components Technical Specification, Part 8 of the ebXML Technical Framework, Version 2.0 (Second Edition) of 15 November 2003 (CCTS) to build the UBL Component Library." needs attention.
There is no methodology in the CCTS, it is a specification for formally defining components. Nor is there a model (there used to be one used as an example). What is there is a meta-model (how to define models). Also, i am not sure we need to say UBL Component Library - it is just UBL Library everywhere else. So how about...
"UBL employs the meta-model described in Core Components Technical Specification, Part 8 of the ebXML Technical Framework, Version 2.0 (Second Edition) of 15 November 2003 (CCTS) to build the UBL Library."
Line 359-360 (section 2. Relationships to ebXML)
The statement "... syntactically specific instantiations such as electronic data interchange and XML." needs clarification.
If this means EDI, then it should say specific syntax instantiations such as UN/EDIFACT, ANSI X12 and XML. EDI is not a syntax.
Line 361-408 (section 2. Relationships to ebXML)
This section is worth promoting into the main UBL document. In the past we have relied on just making references to CCTS, but it may help to include this summary. it will be valuable to more readers than just those interested in the NDRs.
Line 420-421 (section 2.1 Mapping Business Information Entities to XSD)
The statement ... "Both Aggregate and Basic Business Information Entities must have a unique name (Object Class Term)." is not correct. The Object Class Term does not give a Basic Business Information Entity a unique name. Does this mean to say (Dictionary Entry Name) rather than (Object Class Term)?
Line 435 (section 2.1 Mapping Business Information Entities to XSD)
The diagram showing the UBL Metamodel is not quite correct.
a. it should be called the UBL Document Metamodel (we use a different metamodel for conceptual modeling).
a. there is not actually a connection between BBIE and xsd:complexType (except via the Data Type) - more on this later (comments for line 1648)
b. if Message Assembly is supposed to describe a document then it should show them as 'consisting of' one ABIE - the root. This then contains the BBIE and ASBIEs to other ABIEs.
c. can someone explain what an Assembly Component is?
d. the associations between ASBIE and ABIE (and also ASCC and ACC) should be given labels to clarify their meaning. The composition association (with the empty diamond at the ABIE end) is "association aggregated in". the single line association should say "has property of" (an ASBIE's property term refers to an ABIE).
e. the assocation between BBIE and ABIE (and BCC and ACC) should not has "Ass" in its name.
f. the association between Data Type and BBIE (and Data Type and BCC) does not 'define a set of values of', it 'constrains possible values for'. it sets out patterns for valid content - it does not state all possibles values for it.
Line 445-455 (section 2.1 Mapping Business Information Entities to XSD)
This seems rather convoluted. The terms Extrinisc and Intrinsic aren't necessary. Can't it just say that an ASBIE represents an association between ABIEs and that BBIEs define the lowest level components of ABIEs?
Line 447, 448 (section 2.1 Mapping Business Information Entities to XSD)
Isn't it just ccts:AggregateBusinessInformationEntity not ccts:AggregateBusinessInformationEntityProperty?
Line 449 (section 2.1 Mapping Business Information Entities to XSD)
This should say ccts:AssociationBusinessInformationProperty.
Line 468 (section 2.1 Mapping Business Information Entities to XSD)
CCTs are defined, not pre-defined, in the CCTS.
Line 518,522,524 (section 3. General XML Constructs)
Although it is not significant, why alphabetized lists? surely it is better just to follow the sequence suggested in the model - rather than change it. this would mkae it easy to map model objects to schema objects. NB the models do alphabetize the re-usable ABIEs, so the schemas would inherit this anyway.
Line 640 (section 3. General XML Constructs)
A general note that we should always use real UBL examples, i.e. taken from UBL 1.0-beta (and modified if necessary) - not create artifical examples.
Line 655 (section 3.1.1 Root Element)
ELD1 "Each UBL:ControlSchema MUST identify one global element declaration that defines the overall business process being conveyed in the Schema expression." is not an NDR Rule. It should say...
ELD1 "Each UBL:ControlSchema MUST identify one global element declaration that defines the root(or document)ABIE being conveyed in the Schema expression." The NDRs define how to express BIEs not what the BIEs should be.
NB I don't think we have every implemented this rule.
Line 688-747 (section 3.2 Constraints)
This section and the rules it defines is out of scope for the NDR document. It defines the work of the UBL Library Content and as such is not consistent with the main body of the UBL specification document. It can only confuse UBL users. For example:
lines 694-695 state: "A primary component of the UBL library documentation is its dictionary. The entries in the dictionary fully define the pieces of information available for use in UBL business messages."
whereas LC would say...
"A primary component of UBL is its library of re-usable components. The entries in the library fully define the components available for use in UBL business messages."
and
lines 714-715 state: "UBL models and the XML expressions of those models are class driven."
I have no idea what this means but we dont define classes and these dont drive the models - we define specific entities called Business Information Entities or BIEs. Some of these can be described as classes of an object, but this O-O terminology only relates to the naming rules inherited from the ISO 11179.
Line 748 (section 3.3 Reusability Schema)
The heading level is incorrect -it should be higher. This seems to be the style for all this level of heading. The font is smaller than the level below it.
Line 749-750(section 3.3 Reusability Schema)
The statement... "A fundamental question in determining UBL’s approach to developing a reusable library requires a decision on managing by types, or managing by types and elements." needs some explanation. Why is this important? This whole paragraph needs some reworking to make it comprehensible.
Line 757-773 (section 3.3.1 Managing by Types)
This section does not explain how re-usability is affected by this debate. I am not sure it adds any value to the document.
Line 774-843 (section 3.3.1.1 Achieving the Assembly Use Case with Reusable Types)
This needs something that says "We want to provide the smallest granularity of re-usable components, so we define everything globally."
Line 870 (section 3.3.1.2 Reusable Elements)
The statement... "The <Address> element will be reused like this:" should say "The <Address> element can be reused independently of the <Party> element like this:"
line 896-903 (section 3.3.1.2 Reusable Elements)
The arguments given for Codes and Identification schemes being specific to trading partner and small communities apply to all BBIEs, regardless of data type. Any sets of values may be specific to trading partner and small communities. Furthermore, whilst we are attempting to constrain sets for what we call 'code' data types, we are not doing so for 'identifiers'. For at least these two reasons, this argument does not hold. I am sure business experts would disagree with this. particularly the statement "There is no reuse benefit to declaring them as global elements." - isn't that precisely what we want to do with our 'standard' codes.
line 927 (section 3.4.1 Declaring Namespaces)
Shouldn't this be 'schema modules' not 'schema instances'? what is a schema instance?
Line 934 (section 3.4.1 Declaring Namespaces)
"UBL extension methodology will encourage..." should say "Any UBL customization will result in...". We currently have no extension methodology.
Line 938 (section 3.4.1 Declaring Namespaces)
Rule NMS3 states "UBL namespaces MUST only contain UBL developed schema modules." how do we classify the CCT and DT(nee RT) XSDs - they are not purely UBL developed. Presumably one day these will be owned by CEFACT.
Line 983 (section 3.4.4 Persistence)
"[NMS7] UBL published namespaces MUST never be changed." is somewhat ambiguous. Would it be better to say "Each UBL version must retain its original published namespace." Someone could interpret this as saying they must always use the same namespace even if they change things.
Line 1088 (section 3.5 Versioning Scheme)
**warning! polymorphic alert! what does this mean? does it add any value to the statement apart from confusion?
Line 1127 (section 3.6.1 UBL Modularity Model)
as with line 927 - isn't this schema 'module' not 'instance'?
Line 1143 (section 3.6.1 UBL Modularity Model)
In the diagram the name above Data Types package says "...:commonaggregatecomponents:1:0" shouldn't this be "...:datatypes:1:0" (using the existing names for these things)?
Line 1163 (section 3.6.1.2 Module Conformance)
Rule SSM4 "Imported schema modules MUST be fully conformant with UBL naming and design rules." appears draconian. Surely it is better to say "Imported schema modules SHOULD be fully conformant with UBL naming and design rules to promote interoperability and re-use." Many implementors will want to import foreign schemas because they dont rate total interoperability as an objective. Aren't we ourselves toying with this idea for code lists and we may even end up having to do this for the CCT and Rep Terms schemas?
Line 1183 (section 3.6.3 Internal schema modules)
All examples should be taken from UBL 1.0-Beta. In this case it may be hard because I don't think we use any Internal Schema Modules.
Line 1216-1217 (section 3.6.4.1.1 UBL CommonAggregateTypes schema module Namespace)
These two lines appear to have come from the next section "3.6.4.2 UBL CommonBasicTypes schema module".
Line 1346-1347 (section 3.7.1 Embedded documentation)
It is more correct to say "... in the document models', rather than 'library spreadsheets'. This makes it appropriate to all audiences.
Lines 1358-1377 (section 3.7.1 Embedded documentation)[DOC1]
This list misses some important items, such as Property Term. Also, some of these don't belong in the NDR document at all. Only the items necessary for the NDR naming should be specified. Finally, things like UniqueIdentifer and Version and Qualifer Term appear without any reference to why. As far as i know these have never been in any of the versions to date (including those provided by the NDR group).
Line 1402-1433 (section 3.7.1 Embedded documentation) [DOC4]
As per 1358-1377 above.
Also, the unique key for any type of BIE (BBIE, ABIE or ASBIE) is its Dictionary Entry Name. We decided this at UBL 0p70. Or, does this really mean "references a Business Information Entity instance in a unique and unambiguous way"? why would anyone want to create this monsterous overhead for every piece of data? Anyway, putting such data in the schema wouldn't be much use.
Someone needs to confirm the use of the term 'instance' in these rules - I suspect it is not what is meant.
Where are Object Class, Property and Representation Term (the three things that should be here).
What is UsageRule? how are these expressed?
What is Constraint Language? how is it expressed?
Line 1417 and 1420(section 3.7.1 Embedded documentation)
Should these say 'Basic' not 'Aggregate'?
Line 1436-1462 (section 3.7.1 Embedded documentation) [DOC5]
As per 1358-1377 and 1402-1433 above.
Why is Qualifer Term now mandatory? Its definition appears to be that of Object Class Qualifier.
Line 1465-1495 (section 3.7.1 Embedded documentation) [DOC6]
As per 1358-1377 and 1402-1433 above.
Line 1520-1524 (section 3.7.1 Embedded documentation) [DOC8]
This rules confirms the Dictionary Entry Name as the unique key for the library (see 1402-1433 above), but we do not use this syntax. What we have is..
<xsd:documentation>
<ccts:Component>
<ccts:DictionaryEntryName>Dictionary Entry Name</ccts:DictionaryEntryName>
</ccts:Component>
</xsd:documentation>
Isn't this more appropriate?
Line 1567-1571 (section 4.1 General Naming Rules)
I dont think we do (or need to) modify the CCTS naming rules. The CCTS naming rules only apply to Dictionary Entry Names. What the NDR is defining is element naming rules (how we form a UBL Name). If anything, say "the UBL naming rules extend the CCTS naming rules to create XML element names."
Line 1572-1575 (section 4.1 General Naming Rules)
I am not sure we want to make this statement...
"..., UBL will use English as its normative language. If the UBL Library is translated into other languages for localization purposes, these additional languages might require additional restrictions. Such restrictions are expected be formulated as additional rules and published as appropriate." It also does not agree with the rule [GNR1].
Perhaps it should say
"..., UBL will use English as its normative language for XML element, attribute and type names. If the UBL Library is translated into other languages for localization purposes, the semantics for the required language can be provided using translations of the embedded documentation."
Line 1584 (section 4.1 General Naming Rules)
"UBL XML artifact names" should say "XML element and type names".
Line 1585 and 1590 and 1600 (section 4.1 General Naming Rules)
We do not define any attribute names - these are inherited from the CCT schema.
Line 1603-1616 (section 4.1 General Naming Rules)
The whole issue of where and when to use abbrevations is best decided within LC not by NDR rules. Also, the correct terms for what is meant is abbreviations. Abbreviations includes initialisms, acronyms or apocopations(shortening of words).
So, the only NDR rule necessary is...
[GNR4] UBL XML Element, attribute, and Simple and complex type names MUST NOT use abbreviations, except those in the list of exceptions published in Appendix B.
and
[GNR7] The abbreviations listed in Appendix B MUST always be used.
I suggest that the remaining lines 1603 to 1616 be removed to avoid confusion.
Line 1644 (section 4.1 General Naming Rules)
Shouldn't the example of Lower Cammel Case be...
"amountCurrencyCodeListVersionIdentifier" not "AmountCurrencyCodeListVersionIdentifier"
Line 1648 (section 4.2 Type Naming Rules)
We don't currently use complex type definitions for Basic BIEs as they are re-uses of data types (or primary/secondary rep. terms using the old termonology) within the context of a specific ABIE.
e.g. consider the UBL element called BuyersID – there are two separate BBIEs that define a UBL name of BuyersID. This is because they are in two different ABIEs – Order Reference and Line Item. They are semantically different, one defines the way a Buyer identifies their Orders, the other how the Buyer identifies their Line Items. I cannot see how it is meaningful to have an additional definition for BuyersID outside their context. Surely it is more sensible to have separate definitions for Order Reference. Buyers ID and Line Item. Buyers ID. The only re-use they share is that they are both Identifiers. Hence the reason for defining the representation term "Identifier" as the complexType.
Line 1656 (section 4.2.1 Complex Type Names for CCTS Aggregate Business Information Entities)
The statement...
"Accordingly, this ccts:DictionaryEntryName provides a mechanism for ensuring that UBL type names are semantically unambiguous, and that there is no duplication of UBL type names for different type constructs."
would be better phrased as...
"Accordingly, ISO 11179 provides a mechanism for creating UBL element and type names that are semantically unambiguous, and that there is no duplication of UBL type names for different type constructs."
The approach suggested here is not how we have done things before. The approach taken has been to base the type of the ISO 11179 concepts rather than the Dictionary Entry Name as the starting point for element and type names. This is how we have avoided some of the confusion and complexity about defining types that the approach presented here have created.
By starting from the assumption that Dictionary Entry Name gives the types you create the problem that BBIEs and ASBIEs need to have convoluted rules about going from Dictionary Entry Name to Type Name. Don't bother. look at the concepts being applied.
* When we re-use an ABIE it is actually as an association within another ABIE - so it is the ASBIE that has the type of the ABIE.
* We don't re-use BBIE because (by defintion) they are used within one specific ABIE. Only the representation term/data type is re-used.(see Line 1648 and 1656 comment above)
* When we re-use an ASBIE it is actually either as an association with a different ABIE or a different association with the same ABIE. Either way its qualifers are different (thats how we tell them apart)the thing that is re-used is always the type of the ABIE.
I think this has worked well for us to-date and dont see why we need to change it.
Line 1671 (section 4.2.1 Complex Type Names for CCTS Aggregate Business Information Entities)
This appears to be a redundnat sentence. The next sentence says the same thing more clearly.
Line 1674-1688 (section 4.2.2 Complex Type Names for CCTS Basic Business Information Entities)
This approach is unnecessarily complex - see the comment for Line 1656 above.
Line 1729-1731 (section 4.3.1 Element Names for CCTS Aggregate Business Information Entities)
[ELN1] states "A UBL global element name based on an ccts:ABIE MUST be the same as the name of the corresponding xsd:complexType to which it is bound, with the word “Type” removed."
This seems to be the wrong way around. Maybe it should say...
"A UBL global type name based on a ccts:ABIE MUST be the same as the name of the corresponding xsd:element, with the word “Type” appended."
This better fits the actual method.
Line 1752-1765 (section 4.3.2 Element Names for CCTS Basic Business Information Entities)
As discussed in comments for line 1648, it is unnecessary and almost meaningless to define same complexType as element name for BBIEs. They are not going to be re-used. What is re-used is the representation term/data type.
For example, the actual example here should be...
<xsd:element name="ChargeIndicator" type="rt:IndicatorType"/>
This section needs to be re-considered.
Line 1773 (section 4.3.3 Element Names for CCTS Association Business Information Entities)
Shouldn't it be "...of its associated ccts:AggregateBusinessInformation Entity" not "...of its associated ccts:AssociationBusinessInformation Entity"
Line 1775-1780 (section 4.3.3 Element Names for CCTS Association Business Information Entities)
[ELN4] states "A UBL global element name based on an ccts:ASBIE MUST be the ccts:ASBIE dictionary entry name property term and qualifiers; and the object class term and qualifiers of its associated ccts:ABIE. All ccts:DictionaryEntryName separators MUST be removed. Redundant words in the ccts:ASBIE property term or qualifiers and the associated ccts:ABIE object class term or qualifiers MUST be dropped."
Aagain, this seems to be the wrong way around.
"A UBL global type name for a ccts:ASBIE MUST be the same as the name of the associated ccts:ABIE, with the word “Type” appended."
Better fits the way it actually works. For example...
<xsd:element name="PayeeFinancialAccount" type="FinancialAccountType"/>
<xsd:element name="PayerFinancialAccount" type="FinancialAccountType"/>
Line 1790 (section 4.4 Attribute Naming Rules)
This should explain that the ccts:SupplementaryComponent Dictionary Entry Name is defined by the CCTS document. Also, neithe the example (lines 1801 and 1805) or our schemas, follow this rule. We use abbreviations (i.e. we apocopate)...
so...
Quantity Unit. Code List. Identifier becomes unitCodeListID.
and...
Quantity Unit. Code List Agency Name. Text becomes unitCodeListAgencyName
In reality these rules are more like the UBL Name/element rules than the Dictionary Entry Name rules.
Line 1840 (section 5.1.2 Simple Types)
The statement... "most 'simple' data is represented" should say "most Basic BIEs are represented".
Line 1873 (section 5.1.3 Complex Types)
This is a confusing use of the parent-child concept. Perhaps it is supposed to say Association Business Information Entities not Aggregate Business Information Entities?
Line 1887 - 1892 (section 5.1.3.1 Aggregate Business Information Entities)
the statement...
"The relationship expressed by an Aggregate Business Information Entity is not directly represented with a class. Instead, this relationship is captured in UBL with a containment relationship, expressed in the content model of the parent object’s type with a sequence of elements. (Sequence facilitates the use of xsd:extension for versioning and customization.) The members of the sequence – elements which are themselves defined by reference to complex types – are the properties of the containing type."
could be better phrased as...
"The relationship between an Aggregate Business Information Entity and its components is not directly represented. Instead, this is described by its containment, expressed in the ABIE’s type as a sequence of elements. (Sequence facilitates the use of xsd:extension for versioning and customization.) The members of the sequence – elements which may themselves be defined by reference to complex types – are the properties of the containing type."
Line 1921 - 1937 (section 5.1.3.2 Basic Business Information Entities)
The ccts:BBIE xsd:complexType will always be a primary or secondary representation term, so rules [CTD5 CTD6,CTD7 and CTD8] are not necessary. (see comments for line 1648)
Line 1967-1969 (section 5.3.3 Representation Terms)
It appears as if this issue is still being worked through, so it may be best to avoid committing to any rules yet.
Line 2031 (section 5.1.3.5 Supplementary Components)
Doesn't this example pre-suppose that the code list mechanism has been defined this way?
Line 2090-2092 (section 5.2.2 Elements Bound to Complex Types)
It is unclear what 'corresponding' actually means. If it means each is defined as an xsd:complexType, then the same would apply to ccts:AssociationBusiness InformationEntities. If it means the xsd:complexType name is the same as the UBL elements (with the word Type added) then this comes back to the comments earlier (line 1648, 1656, etc.). Only ABIEs will have xsd:complexTypes of the same name (with the word "Type" added).
Line 2093-2094 (section 5.2.2 Elements Bound to Complex Types)
[ELD3] the phrase "For every class..." should be "For every BIE...". We do not use the term class in our modeling.
Line 2103-2107 (section 5.2.2 Elements Bound to Complex Types)
This example is not a re-use of Party as BuyerParty. In fact, it highlights a misunderstanding of what is re-use and what is extension. BuyerParty is an ABIE in its own right. It could be called BuyerAccount - the name is not anything that necessarily connects BuyerParty to Party. In fact, BuyerParty does contain Party details along with other BBIE properties that make it an extension of the Party (or PartyType). But it is not a re-use of Party. What we are saying is that when we have a thing called BuyerParty it is an aggregation, comprising of a Party structure (which does re-use the PartyType) plus several means of identifying the account of the Buyer. You can think of this as extending an ABIE at the modeling level. We use this quite a bit in UBL and it has proven an elegant solution.
A better example of what this section wants to show is...
<xsd:element name="DeliverToAddress" type="AddressType"/>
<xsd:element name="JurisdictionAddress" type="AddressType"/>
<xsd:element name="RegistrationAddress" type="AddressType"/>
<xsd:element name="SendFromAddress" type="AddressType"/>
<xsd:element name="Address" type="AddressType" />
<xsd:complexType name="AddressType">
.............
</xsd:complexType>
Line 2110 (section 5.2.2 Elements Bound to Complex Types)
UBL does not define BCCs, so we should remove this from the rule.[ELD4]
Line 2114 (section 5.2.2.1 Elements Representing ASBIEs)
There is a incorrect space between AS and BIE in the title.
Line 2114-2119 (section 5.2.2.1 Elements Representing ASBIEs)
These lines repeat from lines 1768-1774. Is that intentional?
Line 2130 (section 5.2.3 Code List Import)
[ELD6] states "The code list xsd:import element MUST contain the namespace and schema location attributes." Doesn't this have to be decided by the CLSC?
Line 2150-2152 (section 5.3.1 User Defined Attributes)
rule [ATD1] states "User defined attributes SHOULD NOT be used. When used, user defined attributes MUST only convey CCT:SupplementaryComponent information."
How does this fit with the idea that user defined Data Types can add new attributes?
Line 2155-2156 (section 5.3.1 User Defined Attributes)
rule [ATD6] states "... contains one or more common attributes that apply to all UBL elements...". Does this mean attribute 'values' that apply to all UBL elements? If not, then they all contain at least one common attribute called "name".
Line 2187-2199 (section 6 Code Lists)
What this should be defining is enumerated lists or strictly speaking 'constrained sets of values' for an element. The fact that some are codes is not the issue. For exmaple, identifiers are also constrained sets of values and may also use enumerated lists.
Line 2201-2217 (section 6 Code Lists)
Rules CDL2, CDL3, and CDL4 are business and modeling rules and should not be part of the NDR for XML schemas.
Line 2223-2226 (section 6 Code Lists)
There are three possible sources of code values: UBL originated and maintained, 3rd party values maintained by UBL and 3rd party values maintained by 3rd parties (who may not be the same as the value provider).
How can we control the name of the modules with these latter group? Don't we still want to use these codes?
Line 2230-2235 (section 6 Code Lists)
Rule CDL8 is a business rule and should not be part of the NDR for XML schemas.
line 2251 and 2253 (section 6 Code Lists)
The current CCTS and its schema lists...
<xsd:attribute name="listID" type="xsd:token" use="optional"/>
<xsd:attribute name="listAgencyID" type="xsd:token" use="optional"/>
<xsd:attribute name="listAgencyName" type="xsd:token" use="optional"/>
<xsd:attribute name="listName" type="xsd:token" use="optional"/>
<xsd:attribute name="listVersionID" type="xsd:token" use="optional"/>
<xsd:attribute name="name" type="xsd:token" use="optional"/>
<xsd:attribute name="languageID" type="xsd:language" use="optional"/>
<xsd:attribute name="listURI" type="xsd:anyURI" use="optional"/>
<xsd:attribute name="listSchemeURI" type="xsd:anyURI" use="optional"/>
Of these, which is Code List. Identification. Identifer and which is ListID?
line 2254 (section 6 Code Lists)
What is missing here is an rule for forming the name of a list of codes.
line 2258-2259 (section 6 Code Lists)
What is "List"? the definition says "The default agencies used are those from DE 3055. However, roles defined in DE 3055 MUST NOT be used." but i cannot see how that fits with this structure?
Line 2262-2276 (section 6 Code Lists)
This seems more like a generic URN rule and perhaps should be in the Namespaces section (3.4).
Line 2358-2366 (section 8.1 Root Element)
The naming of root elements (i.e. the root ABIE for a document) is not an NDR rule. It is a business rule.
Line 2371-2373 (section 8.1 Root Element)
The sentence "Schema provide the necessary mechanism for ensuring that instance documents do in fact support these requirements." - is a bit ambitious. It would be more correct to say "Schema provide mechanisms for validating that instance documents do in fact comply to some of these requirements."
Schemas are passive validators. They do not cover dependency rules (e.g. "Orders over $100,000 require full contact details") or integrity rules (e.g. "Either a credit card or a bank account must be given" and many other requirements. Business information exchanges also require these active validations but they can only be done using procedural rules (which is why Schematron was invented!).
Line 2402-2418 (section 8.5 Empty Content)
This is not only unenforcable, but it is not an NDR rule either. it is business practice that will determine the use of elements. At best, we can recommend people don't do it.
This section does not belong in this document.
Line 2467 (Appendix B Approved Acronyms and Abbreviations)
The title should be 'Approved Abbreviations'. Abbreviations include initialisms, acronyms and apocopations.
Line 2470 (Appendix B Approved Acronyms and Abbreviations)
DUNS would be most likely used as an Agency ID value - so i suggest we dont need it here. It is not normally a property term.
There are also some entries missing here...
GUID "Globally Unique Identifier"
UNDG "United Nations Dangerous Goods"
CV2 "Credit Card Verification Numbering System"
Line 2477 (Appendix C Technical Terminology)
This is worth promoting or duplicating in the main specification document as it should be consistent across all UBL.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]