OASIS Universal Business Language (UBL) TC

 View Only
  • 1.  Agreed Schema Changes

    Posted 03-10-2005 13:17
     MHonArc v2.5.0b2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    ubl message

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


    Subject: Agreed Schema Changes


    Folks / David
    
    Please find below a list of agreed changes to Schema
    generation in the first of two Schema development stages
    towards UBL 1.1.
    
    Sylvia Webb will shortly send an abbreviated list of actual
    change tasks but the following / attached give the decisions
    made on which such changes will be based.
    
    Many thanks
    
    Stephen Green
    
    
    
    Agreed First Specification of Schema Changes Required for UBL Version 1.1  (10th March 2005)
    --------------------------------------------------------------------------------------------
    
    
    There are still some matters concerning the following rules which
    remain undecided but there seems to be sufficient decided in the 
    following to allow some Schema generator work to begin.
    
    A second phase of development will be needed to support further
    design agreements (including codelist decisions).
    
    The following changes were agreed in the Atlantic TC call on March 9.
    
    A summary list of actual change details is to be provided shortly to
    supplement this list.
    
    
    
    CHANGE REQUIREMENTS (10th March 2005)
    
    
    Schema changes required by NDR version 1.1 work in McLean Feb 2005
    (note that this list excludes for the timebeing a possible further set
    of codelist Schema change requirements):
    
    
    C1. Changes to Rule DOC8 now states the following:
    
    "The xsd:documentation element for every Supplementary Component
    attribute declarationType MUST contain a structured set of annotations in the 
    following sequence and pattern: 
    � Name (mandatory): Name in the Registry of a Supplementary Component of 
    a Core Component Type. 
    � Definition (mandatory): A clear, unambiguous and complete explanation of 
    the meaning of a Supplementary Component and its revlevance for the related 
    Core Component Type. 
    � Primitive type (mandatory): PrimitiveType to be used for the representation 
    of the value of a Supplementary Component. 
    � Possible Value(s) (optional): one possible value of a Supplementary 
    Component."
    
    Please add xsd:documentation to every Supplementary Component attribute 
    where it is declared in the common Schemas (CCT, UDT and SDT) and codelist 
    Schemas. 
    
    The last clause of the rule is yet to be discussed sufficiently and is excepted 
    from this round of Schema generator development.
    
    
    
    
    C2. The rule DOC9 is yet to be discussed sufficiently and is excepted from
    this round of Schema generator development.
    
    
    
    
    C3. New Rule CTD20 states:
    
    "For every property identified in the UBL model a named XSD:ComplexType
    must be defined"
    
    It is agreed that this rule should be implemented in this round of Schema 
    generation.
    
    
    
    C4. VER8 and VER9 implementation:  To be decided. 
    
    
    
    
    The following change has been agreed apart from the ordering
    of Schema imports and there remains disagreement about how much
    the ordering of XSD attribute-related should be specified.
    Additions may be made later to comply with VER8 and VER9 
    (derivation) requirements.
    
    Conformance to this rule is requested for this round of Schema
    generation development.
    
    C5. 1.1 Schema layout required by the currently amended rule GSX1
         with added agreements/comments in square brackets and 
         with a), b), etc denoting subsections for clarity
    
    
    [GXS1]
    UBL Schema MUST conform to the following physical layout as applicable:
    
    
    a)
    
    XML Declaration
    
    i.e. <?xml version="1.0" encoding="UTF-8"?>
    
    
    b)
    
    Schemas should include comment section separator.
    
    <!-- ===== Copyright Notice ===== -->
    
    
    c)
    
    Required OASIS full copyright notice.
    
      "Copyright ? 2001-2004 The Organization for the Advancement of Structured
      Information Standards (OASIS). All rights reserved.
    
    Copyright text should be taken verbatim from OASIS:
    http://www.oasis-open.org/who/ipr/intellectual_property_2000-1-13.php
    section OASIS.IPR.4.Notices, subsections (A), (B), (C), and,
    when applicable, subsection (D).
    
    (This is a new ipr policy for OASIS and takes effect on 15 April 2005.)
    
    
    d)
    
    In addition, the following fields should be included in the header comment,
    below the copyright:
    
    OASIS Open (http://www.oasis-open.org/)
    Universal Business Language Specification
        (http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ubl)
    Document Name: <insert document name w/o suffix>
    Generated On: <insert date with timestamp>
    
    
    e)
    
    They should be clearly separated from the copyright notice.
    A single dashed line should be used as the separator.
    
    
    f)
    
    <!-- ===== xsd:schema Element With Namespaces Declarations ===== -->
    
    Schemas need to be updated to include this comment line.
    
    
    g)
    
    xsd:schema element to include version attribute and namespace declarations in
    the following order:
    
      xmlns:xsd
    
    [Schemas already conform with above line.]
    
      Target namespace
      Default namespace
      CommonAggregateComponents
      CommonBasicComponents
      CoreComponentTypes
      Unspecialized Datatypes
      Specialized Datatypes
      Identifier Schemes
      Code Lists
    
    [Schemas currently don't conform to this order.
    Order needs review for technical issues, but otherwise is fine as in rule.
    Schemas need to be updated to conform to this order (unless technical
    reason for altering the order).]
    
    
    
    [NOTE: Not all schemas need to include all the following declarations.
    'As applicable', in the opening sentence
    of the rule, means these can be present or not present, as needed, as long
    as they are in this order. This applies to several of the following cases]
    
    h)
    
    Attribute Declarations:
    
    elementFormDefault="qualified"
    attributeFormDefault="unqualified" 
    
    [schemas currently conform to the two lines above.]
    
    
    i)
    
    <!-- ===== Imports ===== -->
    
    [Schemas do not have this comment line.
    Add this to schemas (unless there are no imports)]
    
    
    j)
    
      CommonAggregateComponents schema module
      CommonBasicComponents schema module
      Unspecialized Types schema module
      Specialized Types schema module
    
    [Schemas don't currently conform to this order.
    Change schemas to conform to this order unless
    technically problematic or non-standard. Some 
    have added that the order is only important
    for the sake of specification of some order
    and note that there is no other technical 
    requirement to adhere to any particular order so
    if for some technical reason the order cannot
    be maintained in generation that is understood.]
    
    
    k)
    
    
    [There will be further discussion later about specifying 
    in the Rule the following which are currently already included
    by the Schema generator
      - any codelist schemas
      - cc parameters schema]
    
    
    l)
    
    
       <!-- ===== Global Attributes ===== -->
       Global Attributes and Attribute Groups
    
    [The Schemas already conform to this.
    Add global attribute or attribute groups here,
    and add comment section separator when they are present.]
    
    
    m)
    
      <!-- ===== Root Element ===== -->
      Root Element Declaration
      Root Element Type Definition
    
    [This is how it is now in schemas,
    but schemas need to add comment section separator.]
    
    
    n)
    
      <!-- ===== Element Declarations ===== -->
      alphabetized order
    
    [This is how it is now in schemas,
    but schemas need to add comment section separator.]
    
    [Further discussion will consider the following additions to the rule
    about setting the alphabetical order: ignore case
       (i.e., fold case), and ignore the xsd-related suffix "type" when
       it's there purely for xsd reasons.]
    
    
    o)
    
      <!-- ===== Type Definitions ===== -->
      All type definitions segregated by basic and aggregates as follows
    
    [Schemas should add comment section separator.]
    
    
    p)
    
      <!-- ===== Aggregate Business Information Entity Type Definitions ===== -->
      alphabetized order of AggregateBusinessInformationEntity TypeDefinitions
    
    
    [Schemas should include comment section separator if section has content.]
    
    
    
    q)
    
      <!-- =====Basic Business Information Entity Type Definitions ===== -->
      alphabetized order of BasicBusinessInformationEntities
    
    [Schemas should include comment section separator if section has content.]
    
    
    
    [Note: there still needs to be review of the Parameters (CCTS) Schema and
    the above may need revision  for codelist Schemas depending on the outcome
    of codelist Schema design decisions. Further changes may be required later to 
    conform to VER8 and VER9 too.] 
    
    
    
    
    
    
    


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