[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. (xmlns:xsd=http://www.w3.org/2001/xmlSchema) ------------------------------------------------------------------------ [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 SoftML Tel: +65-6820-2979 Fax: +65-6743-7875 Email: cheekai@SoftML.Net http://SoftML.Net/ On Tue, 10 Jun 2003, CRAWFORD, Mark wrote: >>Folks, >> >>Attached is a work in progress (wordsmithing), however it would be helpful if everyone could read through and identify any showstoppers. >> >>Mark >> >> <<ubl rules.doc>> >>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]