FW: [ubl] UBL-QualifiedDatatypes-2.0.xsd

["Sylvia Webb" <swebb@gefeg.com>]

Mike,

This is what I've learned about the qDT's.  

Regards,
Sylvia 

-----Original Message-----
From: David Kruppke [mailto:kruppke@gefeg.com] 
Sent: Thursday, September 07, 2006 1:51 AM
To: swebb@gefeg.com; GrimleyMJ@Npt.NUWC.Navy.Mil
Cc: 'Frank Rast (E-Mail)'; Michael Dill
Subject: AW: [ubl] UBL-QualifiedDatatypes-2.0.xsd

Hi Sylvia,

we implemented it this way because of harmonisation.


[CTD23]	Every qualified datatype based on an unqualified datatype
xsd:complexType whose supplementary components do not map directly to the
properties of an XSD built-in data type
		    MUST be defined as an xsd:complexType
		    MUST contain one xsd:simpleContent element
		    MUST contain one xsd:restriction element
		    MUST include the unqualified datatype as its xsd:base

This rule applies to all QDT based on complex UDT. But in case of code lists
this rule cannot work:

Example from UBL 1.0:


...

  <xsd:simpleType name="AcknowledgementResponseCodeContentType">
    <xsd:restriction base="xsd:normalizedString">
      <xsd:enumeration value="OrderResponse"/>
      <xsd:enumeration value="OrderResponseSimple"/>
    </xsd:restriction>
  </xsd:simpleType>

<xsd:complexType name="AcknowledgementResponseCodeType">
    <xsd:simpleContent>
      <xsd:extension base="AcknowledgementResponseCodeContentType">
        <xsd:attribute name="codeListID" type="xsd:normalizedString"
fixed="Acknowledgement Response" use="optional"/>
        <xsd:attribute name="codeListAgencyID" type="xsd:normalizedString"
fixed="UBL" use="optional"/>
        <xsd:attribute name="codeListAgencyName" type="xsd:string"
fixed="OASIS Universal Business Language" use="optional"/>
        <xsd:attribute name="codeListName" type="xsd:string"
fixed="Acknowledgement Response" use="optional"/>
        <xsd:attribute name="codeListVersionID" type="xsd:normalizedString"
fixed="1.0" use="optional"/>
        <xsd:attribute name="name" type="xsd:string" use="optional"/>
        <xsd:attribute name="languageID" type="xsd:language" fixed="en"
use="optional"/>
        <xsd:attribute name="codeListURI" type="xsd:anyURI" use="optional"/>
        <xsd:attribute name="codeListSchemeURI" type="xsd:anyURI"
fixed="urn:oasis:names:specification:ubl:schema:xsd:AcknowledgementResponseC
ode-1.0" use="optional"/>
      </xsd:extension>
    </xsd:simpleContent>
  </xsd:complexType>

...

As you can see, there is an QDT called "AcknowledgementResponseCodeType".
This QDT is "based on" udt:CodeType and this UDT is a ComplexType. According
to CTD23 this "AcknowledgementResponseCodeType" had to be based via
xsd:restriction on udt:CodeType. But it is an extension of a
content-simpleType that restricts the codes. The connection "based on" to
udt:CodeType is more virtual.

In order to have a consistent algorithm, we do this for all QDT:

1. If base UDT is simple, the QDT is simple, contains some restriction
values and is a xsd:restriction of the same xsd-built-type like the base
UDT.
2. If base UDT is complex, the QDT is complex, the restriction values are
stored in a content-simpleType that is a xsd:restriction of the same
xsd-built-type like the base UDT. The QDT is then an extension of this
content-simpleType. If there are no restriction values, no
content-simpleType is created, the QTD exents directly the same
xsd-built-type like the base UDT.

I think this is consistent and simple and has no influence on the function
of the QDT. Apart from the fact, that we cannot use rule CTD23 than we have
to create some things the "AcknowledgementResponseCodeType".


Best Regards



David










we don't distingush between QDT's that restrict some codes or whatever and
those that do not. If a QDT has some restrictions a content-simpleType is
created that holds the restriction values. If the base UDT is simple the QDT
is a simpleType that restricts this content-simpleType, if the base UDT is
complex the QDT is a complexType that extents this content-simpleType by
adding some Supplementaries. If there are no rstriction values the QDT
restricts resp. extents the same xsd-built-in type like the base UDT.












> -----Ursprungliche Nachricht-----
> Von: Sylvia Webb [mailto:swebb@gefeg.com]
> Gesendet: Mittwoch, 6. September 2006 16:38
> An: 'Frank Rast (E-Mail)'
> Cc: Kruppke, David
> Betreff: FW: [ubl] UBL-QualifiedDatatypes-2.0.xsd
>
>
> Hi Frank,
>
> Can you explain why "As currently implemented, the type definitions 
> have <xsd:extension base="xsd:normalizedString"> rather than 
> <xsd:restriction base="udt:CodeType"> ?
>
> I understand why the other problems exist. The spreadsheets are wrong.
>
> Thanks,
> Sylvia
>
> -----Original Message-----
> From: Grimley Michael J NPRI [mailto:GrimleyMJ@Npt.NUWC.Navy.Mil]
> Sent: Tuesday, September 05, 2006 10:45 AM
> To: UBL List (ubl@lists.oasis-open.org)
> Subject: [ubl] UBL-QualifiedDatatypes-2.0.xsd
>
>
> [CTD20]	A ccts:QualifiedDataType MUST be based on an
> unqualified data type
> and add some semantic and/or technical restriction to the unqualified 
> data type.
>
> [CTD23]	Every qualified datatype based on an unqualified datatype
> xsd:complexType whose supplementary components do not map directly to 
> the properties of an XSD built-in data type
> 		    MUST be defined as an xsd:complexType
> 		    MUST contain one xsd:simpleContent element
> 		    MUST contain one xsd:restriction element
> 		    MUST include the unqualified datatype as its xsd:base
attribute 
> =====================================================================
>
> NOTE:  MUST contain one xsd:restriction element
>             MUST include the unqualified datatype as its xsd:base 
> attribute
>
> As currently implemented, the type definitions have
>
>     <xsd:extension base="xsd:normalizedString">
>
> rather than
>
>     <xsd:restriction base="udt:CodeType">
>
>
> Thanks,
> Mike
>
>
>