OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

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


Subject: Re: [ubl] [ver] a prototype that works


Folks,

Looking again at the prototype design
and comparing with Arofan's the main
difference is that Arofan's demonstrates
that there is no need for the change to
the complex type name.

I had:-


<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"; xmlns="Invoice-2.1"
xmlns:in="Invoice-2.0" xmlns:cac="CommonAggregateComponents-2.0"
xmlns:cac11="CommonAggregateComponents-2.1"
xmlns:cbc="CommonBasicComponents-2.0"
xmlns:cbc11="CommonBasicComponents-2.1" targetNamespace="Invoice-2.1"
elementFormDefault="qualified" attributeFormDefault="unqualified"
version="2.1-prototype-ver-sdg-1">
 <!-- ===== Imports ===== -->
 <xsd:import namespace="Invoice-2.0"
schemaLocation="../../xsdrt-2-0-prototype-ver-sdg-1/maindoc/Invoice-2.0.xsd"
/>
 <xsd:import namespace="CommonAggregateComponents-2.1"
schemaLocation="../common/CommonAggregateComponents-2.1.xsd"/>
 <xsd:import namespace="CommonBasicComponents-2.1"
schemaLocation="../common/CommonBasicComponents-2.1.xsd"/>
 <!-- ===== Element Declarations ===== -->
 <!-- ===== Root Element ===== -->
 <xsd:element name="Invoice" type="InvoiceBaseType"
substitutionGroup="in:Invoice"/>
 <!-- ===== Type Definitions ===== -->
 <!-- ===== Aggregate Business Information Entity Type Definitions ===== -->
 <!--  example addition 1 - InspectionDate added to Invoice -->
 <xsd:complexType name="InvoiceBaseType">
  <xsd:complexContent>
   <xsd:extension base="in:InvoiceType">
    <xsd:sequence>
     <xsd:element ref="cbc11:InspectionDate" minOccurs="0"/>
    </xsd:sequence>
   </xsd:extension>
  </xsd:complexContent>
 </xsd:complexType>
</xsd:schema>


But this could otherwise be:-

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"; xmlns="Invoice-2.1"
xmlns:in="Invoice-2.0" xmlns:cac="CommonAggregateComponents-2.0"
xmlns:cac11="CommonAggregateComponents-2.1"
xmlns:cbc="CommonBasicComponents-2.0"
xmlns:cbc11="CommonBasicComponents-2.1" targetNamespace="Invoice-2.1"
elementFormDefault="qualified" attributeFormDefault="unqualified"
version="2.1-prototype-ver-sdg-2">
 <!-- ===== Imports ===== -->
 <xsd:import namespace="Invoice-2.0"
schemaLocation="../../xsdrt-2-0-prototype-ver-sdg-2/maindoc/Invoice-2.0.xsd"
/>
 <xsd:import namespace="CommonAggregateComponents-2.1"
schemaLocation="../common/CommonAggregateComponents-2.1.xsd"/>
 <xsd:import namespace="CommonBasicComponents-2.1"
schemaLocation="../common/CommonBasicComponents-2.1.xsd"/>
 <!-- ===== Element Declarations ===== -->
 <!-- ===== Root Element ===== -->
 <xsd:element name="Invoice" type="InvoiceType"
substitutionGroup="in:Invoice"/>
 <!-- ===== Type Definitions ===== -->
 <!-- ===== Aggregate Business Information Entity Type Definitions ===== -->
 <!--  example addition 1 - InspectionDate added to Invoice -->
 <xsd:complexType name="InvoiceType">
  <xsd:complexContent>
   <xsd:extension base="in:InvoiceType">
    <xsd:sequence>
     <xsd:element ref="cbc11:InspectionDate" minOccurs="0"/>
    </xsd:sequence>
   </xsd:extension>
  </xsd:complexContent>
 </xsd:complexType>
</xsd:schema>


I'd also note that there might be extra design considerations to help if
there were to be
a mapping to a redeclaration/non-polymorphic design (with local declarations
as in
ATG2's NDR) supported by a stylesheet say. Then we might want to help a
transformation by deriving *every* element with a substitutionGroup headed
by the
previous version global element, even when extension wasn't required by the
model.
This would get all the information into each Schema rather than relying on
more
complex parsing (perhaps with XSLT 2.0) to get it from the imported Schema
(I've no
idea yet how this might be done without looking at it further but I reckon
it should be
possible). Then a UBL polymorphic Schema might be always readily transformed
(with XSLT, say, or XQuery) into the ATG2 NDR equivalent for validation by
both
of the same instance. This might also remove the need for extra prefixes for
common
aggregate components.

The above might be needed all the more so where there were further minor
versions.
It might give a more level structure for the design of imports and
derivations in the
second and subsequent minor versions (otherwise some derivations would be
based
on the previous version and others on the version before or the one before
that).

I'm not sure that all this can be achieved if there were to be minor
versions with the
same namespaces as the previous major version (if that is desirable).
Perhaps it
would require includes rather than imports. It would probably require more
extensive
rewriting of the NDRs.

All the best

Steve



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