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


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-ndrsc message

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

Subject: Re: [ubl-ndrsc] UBL Schema NDR Checklist

[R 3]	Each dictionary entry name must define one and only one
fully qualified path (FQP) for an element or attribute. 

CK: Seems to suggest that dictionary entry name use XPath,
but then current usage of dictionary entry name doesn't do that.
So which is which?


[R 5]	XML names constructed from dictionary entry names must not include
periods, spaces, or other separators.

CK: Underscores (_) used as first character to denote "internal
usage of some sort" need not be considered separators, but should
presumably fall under this guidance of usage avoidance.  So
suggest that "separators" be replaced by 

"any other character than the 52 upper and lower case alphabets and the
10 digit characters.  In other words, the XML names in UBL should be 
drawn from the regular expression set [a-zA-Z]+[a-zA-Z0-9]*"

Note: this would also help mapping to the namespaces of other 
languages such as Java.


[R 6]	Names must not use acronyms, abbreviations, or other word
truncations, with the following list of exceptions:

CK: Sentence incomplete.  What are the exceptions?

Currently, in Reusable.xsd, there are definitions of
  <xsd:element name="BuyersID" type="cct:IdentifierType" /> 
  <xsd:element name="CV2" type="cct:TextType" /> 
  <xsd:element name="UNDGCode" type="cct:CodeType" /> 

which contain an abbreviations.  Are these elements invalid?
Or should [R6] be relaxed a little?  Though listing them in
the list of exceptions may solve existing usage, what about
cases when within individual user's context, certain abbreviations
are standard usages within their industry or consortiums but
not listed in the exceptions here?


[R 7]	Names must not contain non-letter characters unless required by
language-specific rules.

CK: Made redundant by [R5] modification above.


[R 18]	If the object class term would have been helpful in the resulting
XML name for clarity, or if needed to differentiate the element and allow
it to have a different type association, it should be repeated in the
property qualifier field. 

CK: Please define a measure of "clarity".


[R 21]	Each CCT must have at least one corresponding unique complex type
and simple type, where the elements content (governed by the
xs:simpleContent construct and the CCTs simple type) represents the
content component of the CCT and whose attributes (defined in the complex
type) each represent a supplementary component of the CCTs.

CK: Use of "xs:simpleContent" conflicts with [R 107]

[R 107]	The XSD prefix MUST be used.


[R 22]	The complex type name corresponding to a CCT must be the CCT name,
with the periods and spaces removed. 

CK: Make all name-construction guidances point to the modified [R 5].
So it reads something like:
"[R 22]	The complex type name corresponding to a CCT must be the CCT name,
an XML name constructed following [R 5]".


[R 23]	The name of the simple type corresponding to the content component
of a CCT must be the content component name, with the periods and spaces
removed and with Type added to the end.

[R 24] ... with the periods and spaces removed....

CK: Guidance on "with the periods and spaces removed" should point
back to [R 5].  So all name construction rules are standardised
leaving no gray area to individual references to name construction.


[R 30]	Every type definition and element declaration must contain a
structured set of annotations in following pattern, where the keyword is
typically based on the spreadsheet column heading in the syntax-neutral
model and the description is typically based on the content of the
spreadsheet field:

CK: Pattern not listed after ending colon.


to be continued....

Best Regards,
Chin Chee-Kai
Tel: +65-6820-2979
Fax: +65-6743-7875
Email: cheekai@SoftML.Net

On Tue, 10 Jun 2003, CRAWFORD, Mark wrote:

>>Attached is a work in progress (wordsmithing), however it would be helpful if everyone could read through and identify any showstoppers.
>> <<ubl rules.doc>> 

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