[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl] UBL-QualifiedDatatypes-2.0.xsd
Sylvia (and David),
Thanks. I do have a question though...
Does ATG2 intend to modify its NDR rule R 156:
[R 156] Every qualified data type based on an unqualified data type xsd:complexType whose supplementary components do not map directly to the properties of a XSD built-in data type
MUST be defined as a xsd:complexType
MUST contain one xsd:simpleContent element
MUST contain one xsd:restriction element
MUST include the unqualified data type as its xsd:base attribute.
We made a conscious decision to adopt their QDT rules in the interests of harmonization.
Thank You,
Mike
-----Original Message-----
From: Sylvia Webb [mailto:swebb@gefeg.com]
Sent: Thursday, 07 September 2006 0909
To: ubl@lists.oasis-open.org
Subject: FW: [ubl] UBL-QualifiedDatatypes-2.0.xsd
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
>
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]