UBL Naming and Design Rules SC

 View Only

Re: [ubl-ndrsc] UBL Schema NDR Checklist

  • 1.  Re: [ubl-ndrsc] UBL Schema NDR Checklist

    Posted 06-11-2003 04:33
    
    
    ------------------------------------------------------------------------
    [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>> 
    >>