OASIS Open Mailing List Archives  ·  All Lists  ·  ubl  ·  2004-03

ubl — archive

[Date Prev]  |  [Thread Prev]  |  [Thread Next]  |  [Date Next]   —  [Date Index]  |  [Thread Index]  |  [Month Index]  |  [List Home]

Outcomes of joint SC call 2004.03.30

 MHonArc v2.5.0b2 -->

















ubl message








[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [List Home]











Subject: Outcomes of joint SC call 2004.03.30












Attendance:

   Jon Bosak
   Tony Coates
   Bill Meadows
   Anne Hendry
   Stephen Green
   David Kruppke
   Tim McGrath
   Marion Royal
   Lisa Seaburg

Item 1

   Schedule for this week

   Agreed:

   * Tuesday/Wednesday - agree and document change requests for GEFEG
   * Submit one official set of final changes to GEFEG
   * Formalize and schedule QA and sign off from GEFEG

Item 2.1

   Correctly defining re-usable BBIE Properties (Mike Grimley)

   Resolution:

   AI: Mike G.: Clarify rule for how the name of each complex type
       used for BBIE properties should be formed; David needs a
       rule, not just an example
   AI: NDRSC: Include rule in NDRs
   AI: David: Implement the change 

   Reference: Message from Mike dated 26 March: "Draft 10.1 Schema
   Review - CBC Schema"; copy appended below

Item 2.2

   Agreed implementation of Code List Representation schema (Marty
      Burns/Stephen Green)

   Discussion: This is required for compliance with the CLSC
   design and involves some important functionality (the ability
   to validate CL attribute values).

   Resolution: Apply the changes per emails from Stephen and Tony.
   This will require more changes to the model and will require
   2-3 days to implement.

   AI: Tim: Create an SDT model for UBL_Amount. Type

   AI: David: Implement the changes in Stephen's message of 27 March 

   Reference: Message from Stephen dated 27 March: "Schema Changes
      Required for further, requested compliance with the CLSC
      Design"; copy appended below

Item 2.3

   Core Component Parameters: maxOccurs for Instance elements
      (Stephen Green)

   AI: Tim: In model draft 11, explicitly state maxOccurrs
       wherever it is not stated in CCP schema module

   AI: Tim: Change "contextualization" to "contextualisation"

Other notes

    - We meet again tomorrow to receive AI's and clarify remaining
      questions.

    - Tomorrow's meeting will start an hour earlier than
      previously scheduled -- 7 a.m. San Francisco time instead of 8.

    - We think that these changes will have no effect on
      instances, so Ken should be able to start work using
      Stephen's instance examples for joinery and office together
      with the draft 10 schemas; Jean will still have to finish
      the UN specifications.  We will visit this again tomorrow to
      confirm.

==================================================================

Date: Fri, 26 Mar 2004 15:41:55 -0500
From: Grimley Michael J NPRI <[email protected]>
To: "UBL List (E-mail)" <[email protected]>
Subject: Draft 10.1 Schema Review - CBC Schema

Greetings,

It looks to me as if the CBC schema has not changed much (if any).

We still have:

    <xsd:element name="StreetName" type="udt:NameType"/>
    <xsd:element name="AdditionalStreetName" type="udt:NameType"/>


We should have:

    <xsd:complexType name="StreetNameType">
        <xsd:simpleContent>
            <xsd:extension base="udt:NameType"></xsd:extension>
        </xsd:simpleContent>
    </xsd:complexType>

    <xsd:element name="StreetName" type="StreetNameType"/>


In the CAC Schema (or wherever), we should see declarations such as:

    <xsd:element ref="cbc:StreetName"/>

    <xsd:element name="AdditionalStreetName" type="cbc:StreetNameType"/>


Reference from NDR (wd-ublndrsc-ndrdoc-V1pt0Draftp.doc):

    [Line 1848]: BBIE properties are represented with complex types.

    [CTD3] Every ccts:BBIEProperty xsd:complexType definition content model MUST use the xsd:simpleContent element.

    [CTD4] Every ccts:BBIEProperty ComplexType content model xsd:simpleContent element MUST consist of an  xsd:extension element. 

    [CTD5] Every ccts:BBIEProperty xsd:complexType content model  xsd:base attribute value MUST be the ccts:CCT of the unspecialised or specialised UBL datatype as appropriate. 

-----

Thank You,
Mike Grimley 

==================================================================

Date: Sat, 27 Mar 2004 21:55:46 -0000
From: "Stephen Green" <[email protected]>
Subject: [ubl] Schema Changes Required for further, requested compliance with the CLSC Design
To: [email protected]

Schema Changes Required for further, requested compliance with the CLSC Design

In draft 10-1 the Codelist Codelist Schema Module starts with the complexType:

<xsd:complexType name="CodeType">
 <xsd:annotation>
  <xsd:documentation>
   <ccts:Component>
    <ccts:ComponentType>DT</ccts:ComponentType>
    <ccts:DictionaryEntryName>Code. Type</ccts:DictionaryEntryName>
    <ccts:RepresentationTerm>Code</ccts:RepresentationTerm>
...   
    <ccts:CodeListUniformResourceID>http://www.bsi-global.com/Technical%2BInformation/Publications/_Publications/tig90x.doc</ccts:CodeListUniformResourceID>
    <ccts:CodeListSchemeUniformResourceID>urn:oasis:names:tc:ubl:codelist:CurrencyCode:1:0-draft-10.1</ccts:CodeListSchemeUniformResourceID>
    <ccts:LanguageID>en</ccts:LanguageID>
   </ccts:Instance>
  </xsd:documentation>
 </xsd:annotation>
 <xsd:simpleContent>
  <xsd:restriction base="udt:CodeType">
   <xsd:enumeration value="AED">
    <xsd:annotation>
     <xsd:documentation>
      <CodeName>Dirham</CodeName>
     </xsd:documentation>
    </xsd:annotation>
   </xsd:enumeration>
      ...
   <xsd:enumeration value="ZWD">
    <xsd:annotation>
     <xsd:documentation>
      <CodeName>Zimbabwe Dollar</CodeName>
     </xsd:documentation>
    </xsd:annotation>
   </xsd:enumeration>
   <xsd:attribute name="name" type="xsd:string" use="optional"/>
   <xsd:attribute name="codeListID" type="xsd:normalizedString" use="optional" fixed="ISO 4217 Alpha"/>
   <xsd:attribute name="codeListAgencyID" type="xsd:normalizedString" use="optional" fixed="6"/>
   <xsd:attribute name="codeListAgencyName" type="xsd:string" use="optional" fixed="United Nations Economic Commission for Europe"/>
   <xsd:attribute name="codeListName" type="xsd:string" use="optional" fixed="Currency"/>
   <xsd:attribute name="codeListVersionID" type="xsd:normalizedString" use="optional" fixed="0.3"/>
   <xsd:attribute name="codeListURI" type="xsd:anyURI" use="optional" fixed="http://www.bsi-global.com/Technical%2BInformation/Publications/_Publications/tig90x.doc"/>
   <xsd:attribute name="codeListSchemeURI" type="xsd:anyURI" use="optional" fixed="urn:oasis:names:tc:ubl:codelist:CurrencyCode:1:0-draft-10.1"/>
   <xsd:attribute name="languageID" type="xsd:language" use="optional" fixed="en"/>
  </xsd:restriction>
 </xsd:simpleContent>
</xsd:complexType>

where the complexType includes, following the 'Component' and 'Instance' annotation/documentation, the enumeration and the Supplementary Components.

A.  The Codelist SC has proposed the following changes:

1.  The complexType above should become a complexType with just the 'Component' and 'Instance' annotation/documentation 
and by necessity (my addition) the Supplementary Components: 

<xsd:complexType name="CodeType">
 <xsd:annotation>
  <xsd:documentation>
   <ccts:Component>
    <ccts:ComponentType>DT</ccts:ComponentType>
    <ccts:DictionaryEntryName>Code. Type</ccts:DictionaryEntryName>
...   
   </ccts:Component>
   <ccts:Instance>
    <ccts:CodeListID>ISO 4217 Alpha</ccts:CodeListID>
    <ccts:CodeListAgencyID>6</ccts:CodeListAgencyID>
...   
   </ccts:Instance>
  </xsd:documentation>
 </xsd:annotation>
 <xsd:simpleContent>
  <xsd:extension base="CurrencyCodeContentType">
   <xsd:attribute name="name" type="xsd:string" use="optional"/>
... 
 (Supplementary Components with fixed values)

   <xsd:attribute name="codeListSchemeURI" type="xsd:anyURI" fixed="urn:oasis:names:tc:ubl:codelist:CurrencyCode:1:0-draft-10.1" use="optional"/>
  </xsd:extension>
 </xsd:simpleContent>
</xsd:complexType>

2.  A new simple type is created too which holds the enumerations and is based on xsd:normalizedString:

<xsd:simpleType name="CurrencyCodeContentType">
 <xsd:restriction base="xsd:normalizedString">
  <xsd:enumeration value="AED">
   <xsd:annotation>
    <xsd:documentation>
     <CodeName>Dirham</CodeName>
    </xsd:documentation>
   </xsd:annotation>
  </xsd:enumeration>
...  
 </xsd:restriction>
</xsd:simpleType>

3.  At the end of the Schema is added

<xsd:attribute name="CurrencyCode" type="CurrencyCodeContentType"/>

This allows us to use the Currency Codelist Schema Module to provide XSD validation 
to, for example, the 'amountCurrencyID' in the Amount Type of the UDT *but to do so restricts the
allowed values in the udt:AmountType* so it has to now be a Specialised DataType, such as sdt:AmountType.

B.  The Specialised DataType Schema Module could then have:

<xsd:restriction base="udt:AmountType">
 <xsd:attribute name="amountCurrencyID" type="cur:CurrencyCodeContentType" use="required"/>

and its amountCurrencyCodeListVersionID could be fixed as is a codelist schema's Supplementary Components 

...
 <xsd:attribute name="amountCurrencyCodeListVersionID" type="xsd:normalizedString" use="optional" fixed="0.3"/>
</xsd:restriction>

There would also, of course, be the need for the cur: namespace declaration and all references
to udt:AmountType could be changed to sdt:AmountType in Document Schema Modules and 
Common Basic Components Schema Modules.

But, since the Codelist Schema Module type has to be a simpleType to allow validation of attributes which are codes
(such as Supplementary Components as we have in AmountType), the udt:CodeType cannot be the base. The simpleType
still has to be based on 'xsd:normalizedString' and the complexType which holds the Supplementary Components is no
longer based on the udtCodeType but has no base type (the link to the udt:CodeType being conceptual).

1.  So a new Specialised DataType Schema Module which allowed the newly-to-be-introduced validation of the Amount currency code
Supplementary Component attribute could look like this:

<xsd:schema targetNamespace="urn:oasis:names:tc:ubl:SpecialisedDatatypes:1:0-draft-10.1" xmlns:udt="urn:oasis:names:tc:ubl:UnspecialisedDatatypes:1:0-draft-10.1" xmlns:xsd="http://www.w3.org/2001/XMLSchema"; xmlns="urn:oasis:names:tc:ubl:UnspecialisedDatatypes:1:0-draft-10.1" xmlns:ccts="urn:oasis:names:tc:ubl:CoreComponentParameters:1:0-draft-10.1" xmlns:cct="urn:oasis:names:tc:ubl:CoreComponentTypes:1:0-draft-10.1" xmlns:cur="urn:oasis:names:tc:ubl:codelist:CurrencyCode:1:0-draft-10.1" elementFormDefault="qualified" attributeFormDefault="unqualified" version="1:0-draft-10.1">
 <xsd:import namespace="urn:oasis:names:tc:ubl:UnspecialisedDatatypes:1:0-draft-10.1" schemaLocation="UBL-UnspecialisedDatatypes-1.0-draft-10.1.xsd"/>
 <xsd:import namespace="urn:oasis:names:tc:ubl:CoreComponentParameters:1:0-draft-10.1" schemaLocation="UBL-CoreComponentParameters-1.0-draft-10.1.xsd"/>
 <xsd:import namespace="urn:oasis:names:tc:ubl:CoreComponentTypes:1:0-draft-10.1" schemaLocation="UBL-CoreComponentTypes-1.0-draft-10.1.xsd"/>
 <xsd:import namespace="urn:oasis:names:tc:ubl:codelist:CurrencyCode:1:0-draft-10.1" schemaLocation="../codelist/UBL-CodeList-CurrencyCode-1.0-draft-10.1.xsd"/>
 <xsd:complexType name="AmountType">
  <xsd:annotation>
   <xsd:documentation>
    <ccts:Component>
     <ccts:ComponentType>DT</ccts:ComponentType>
     <ccts:DictionaryEntryName>Amount. Type</ccts:DictionaryEntryName>
     <ccts:Definition>A number of monetary units specified in a currency where the unit of the currency is explicit or implied.</ccts:Definition>
     <ccts:RepresentationTerm>Amount</ccts:RepresentationTerm>
    </ccts:Component>
   </xsd:documentation>
  </xsd:annotation>
  <xsd:simpleContent>
   <xsd:restriction base="udt:AmountType">
    <xsd:attribute name="amountCurrencyID" type="cur:CurrencyCodeContentType" use="required"/>
    <xsd:attribute name="amountCurrencyCodeListVersionID" type="xsd:normalizedString" use="optional" fixed="0.3"/>
   </xsd:restriction>
  </xsd:simpleContent>
 </xsd:complexType>
</xsd:schema>

2.  The Common Basic Components Schema Module would have to include the SDT namespace, e.g. 

 xmlns:sdt="urn:oasis:names:tc:ubl:SpecialisedDatatypes:1:0-draft-10.1"

and the SDT import, e.g.:

<xsd:import namespace="urn:oasis:names:tc:ubl:SpecialisedDatatypes:1:0-draft-10.1" schemaLocation="../common/UBL-SpecialisedDatatypes-1.0-draft-10.1.xsd"/>

and the use of the sdt:AmountType instead of the udt:AmountType
e.g.
<xsd:element name="Amount" type="sdt:AmountType"/>

and 

<xsd:element name="LineExtensionTotalAmount" type="sdt:AmountType"/>

etc.

This would mean that an instance could now have validation of its Amount amountCurrencyID Supplementary Component e.g.

<cbc:Amount amountCurrencyID="AED" amountCurrencyCodeListVersionID="0.3">3.14</cbc:Amount>

but note that the Amount's CCTS Supplementary Components do not include those found in a cct:Code so as to allow
all the details of the currency codelist to be stated and possibly fixed

Discussion points:  

1. Is the above acceptable or does it introduce the possibility of any serious problems for implementers and users, etc?

2. Can / should the other Supplementary Components such as those found in a Code DataType
be added to the sdt:AmountType in the SDT Schema Module e.g. by extension so as to allow these too to be stated and fixed?

3. Does this matter warrant delaying these CLSC changes too till 1.1 so as to resolve this issue if time does not permit now?
__________________________________________________________________________________________________________________

Stephen Green

















[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [List Home]
[Date Prev]  |  [Thread Prev]  |  [Thread Next]  |  [Date Next]   —  [Date Index]  |  [Thread Index]  |  [Month Index]  |  [List Home]
Preserved under the OASIS Open Mailing List Archives Preservation Initiative.

Message text and metadata preserved from source records; presentation regenerated to restore navigation (as of April 2026).

MarkMail, a mailing-list search service launched by MarkLogic in 2007 as a showcase for its XML full-text search engine, indexed these OASIS archives for many years. It was retired in 2024 following MarkLogic’s acquisition by Progress Software; markmail.org is offline and any markmail.org links in archived messages are no longer functional.