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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev message

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


Subject: Re: [ubl-dev] Creating a new document... where to start?


Steven and all ubl-dev folk,


I'm actually trying to find a clear path in this area too.

I've been trying to 'customize' the reusable ABIEs
using the 'customization methodology' (as described in
the paper in the UBL package by Eduardo Gutentag
and Arofan Gregory et al) so as to define Schemas for
simpler documents of order and invoice which would
also be valid documents by the original order and invoice
Schemas.

I end up with, say, an order looking like the first Schema
at the end of this message and the Common Aggregate
Components Schema like that at the bottom below.

Notice that there are many BBIEs and ASBIEs in the common
Schema with *both* min occurs and max occurs equal to zero
e.g. <xsd:element ref="cbc:District" minOccurs="0" maxOccurs="0">
and that I've imported the original Common Aggregates Schema
and given my schema a new version number.

I'm not sure about the version number, whether in fact I should
have actually given the new Schema a new namespace. The
'customization methodology' paper seems to 'outlaw' (as far
as UBL conformance is concerned) the use of the same namespace
in that it points to the NDR rule against the use of redefine in
UBL Schemas so as to force folk to change the namespace.
However, I'm hoping, I guess, that the situation I'm trying to
cater for warrants exclusion from this rule for the sake of producing
Schemas with a different role. Debatable I suppose.

So this I'd like to discuss at some point: - whether I can get away
with using the same namespace so that the instances created
as valid by the new Schema are exactly the same as if they'd been
created to validate against the original. I hope you'll see more
on this later (e.g. a 'strawman').

For now, leaving aside technicalities like that, what I'd like
to concentrate on is what goes into my new Schema and what is left
out. (It won't be so trivial as to fit in one e-mail.) For the
requirements I'm concerned with it matters that nothing new is added
so that a new invoice is valid as an old one too. But things are taken
away - and this has problems associated with it.
I obviously want to leave behind anything that used to be mandatory
and leave it mandatory (as per customization paper) but I need
to leave anything intact that other documents I intend to build will
need in an ABIE too. I don't want to have more
than one version of the same ABIE or that would require giving one
of them an new name, which I'm not sure I want. Is that right?
If I took too much out of an ABIE (making it 0..0 cardinality), I'd run
the risk that I might have to create another version of that same ABIE
so that it could be used, perhaps, in another document or another place
in a document  and for that I'd have to have one of the two versions
at least called by another name for uniqueness. That I don't want here.

****
I don't want my new instances to be rejected by the original Schemas
but to look to all intents and purposes as if they are just instances
for the original Schemas - to a potential receiving application and
to an auditor or he like at least.
****

What I actually want, and I'd value input into this (as much as
can be mustered) is an order and an invoice which are valid
as proper 'vanilla' (original) UBL according to the original
Schemas, but which are (also) defined by restricted,
secondary Schemas to the extent that small business financial
applications can cope with them properly.

Perhaps someone out there is allowed to share what such
restrictions for small businesses might be.

One idea I have is to look at a paper from a major accounting
company about what constitutes a minimal or optimal
electronic invoice, then derive a respective order requirement
from that. Any ideas?

The next step is to work out a way to model the new document
and then a way to generate the Schemas (even by hand if
necessary, but a tool might eliminate errors better).

I have a few ideas in this direction which I'll hold on to till later
but UBL used spreadsheets to start with for modelling. then
adapted to tool features as neccessary. For now, a starting
point I'd like to try is to add an extra column to the UBL spreadsheet
just after the 'cardinality' column and call it 'new cardinality'
since for what I'd like to do I'm only wishing to restrict the
existing reusable ABIEs. I don't wish to rename anything.

My document models could, perhaps, be new
without restriction, using these adapted ABIEs but otherwise could be
restricted versions of the originals - I'd prefer the latter. What
do others think?

Sorry for such a long e-mail. I'd intended to bring up this issue
of restricted Schemas as a proposal for a set of small business
profiles to lower the barrier to entry for use of UBL in small
business finance applications but I couldn't resist using the issue
to answer the question. Hope it helps.

Anyway, now I've let the matter out about small business profiles,
what do folk think about it? There has been a lot of interest from
modellers and early adopters of UBL.

Catering for Schemas for completely fresh documents might
be the subject of another message later.

All the best

Stephen Green

Here is an order Schema

<xsd:schema [... namespaces, ... imports ] version="0:1-sdg">
<xsd:element name="Order" type="OrderType">
 <xsd:annotation>
  <xsd:documentation>This element MUST be conveyed as the root element in
any instance document based on this Schema expression</xsd:documentation>
 </xsd:annotation>
</xsd:element>
<xsd:complexType name="OrderType">
 <xsd:annotation>
  <xsd:documentation>
   <ccts:Component>
    <ccts:ComponentType>ABIE</ccts:ComponentType>
    <ccts:DictionaryEntryName>Order. Details</ccts:DictionaryEntryName>
    <ccts:Definition>a document that contains information directly relating
to the economic event of ordering products.</ccts:Definition>
    <ccts:ObjectClass>Order</ccts:ObjectClass>
    <ccts:AlternativeBusinessTerms>Purchase
Order</ccts:AlternativeBusinessTerms>
   </ccts:Component>
  </xsd:documentation>
 </xsd:annotation>
 <xsd:sequence>
  <xsd:element name="BuyersID" type="udt:IdentifierType" minOccurs="0">
   <xsd:annotation>
    <xsd:documentation>
     <ccts:Component>
      <ccts:ComponentType>BBIE</ccts:ComponentType>
      <ccts:DictionaryEntryName>Order. Buyers_ Identifier.
Identifier</ccts:DictionaryEntryName>
      <ccts:Definition>a unique identification assigned to the Order in
respect to the Buyer party</ccts:Definition>
      <ccts:Cardinality>0..1</ccts:Cardinality>
      <ccts:ObjectClass>Order</ccts:ObjectClass>
      <ccts:PropertyTermQualifier>Buyers</ccts:PropertyTermQualifier>
      <ccts:PropertyTerm>Identifier</ccts:PropertyTerm>
      <ccts:RepresentationTerm>Identifier</ccts:RepresentationTerm>
      <ccts:DataType>Identifier. Type</ccts:DataType>
     </ccts:Component>
    </xsd:documentation>
   </xsd:annotation>
  </xsd:element>
  ...
lots missing here
  ...


  <xsd:element ref="cac:BuyerParty">
   <xsd:annotation>
    <xsd:documentation>
     <ccts:Component>
      <ccts:ComponentType>ASBIE</ccts:ComponentType>
      <ccts:DictionaryEntryName>Order. Buyer
Party</ccts:DictionaryEntryName>
      <ccts:Definition>associates the Order with information about the buyer
involved in the transaction.</ccts:Definition>
      <ccts:Cardinality>1</ccts:Cardinality>
      <ccts:ObjectClass>Order</ccts:ObjectClass>
      <ccts:PropertyTerm>Buyer Party</ccts:PropertyTerm>
      <ccts:AssociatedObjectClass>Buyer Party</ccts:AssociatedObjectClass>
     </ccts:Component>
    </xsd:documentation>
   </xsd:annotation>
  </xsd:element>
  <xsd:element ref="cac:SellerParty">
   <xsd:annotation>
    <xsd:documentation>
     <ccts:Component>
      <ccts:ComponentType>ASBIE</ccts:ComponentType>
      <ccts:DictionaryEntryName>Order. Seller
Party</ccts:DictionaryEntryName>
      <ccts:Definition>associates the Order with information about the
seller involved in the transaction.</ccts:Definition>
      <ccts:Cardinality>1</ccts:Cardinality>
      <ccts:ObjectClass>Order</ccts:ObjectClass>
      <ccts:PropertyTerm>Seller Party</ccts:PropertyTerm>
      <ccts:AssociatedObjectClass>Seller Party</ccts:AssociatedObjectClass>
     </ccts:Component>
    </xsd:documentation>
   </xsd:annotation>
  </xsd:element>
  <xsd:element ref="OriginatorParty" minOccurs="0">
   <xsd:annotation>
    <xsd:documentation>
     <ccts:Component>
      <ccts:ComponentType>ASBIE</ccts:ComponentType>
      <ccts:DictionaryEntryName>Order. Originator_ Party.
Party</ccts:DictionaryEntryName>
      <ccts:Definition>associates the Order with information about the
originator of the transaction.</ccts:Definition>
      <ccts:Cardinality>0..1</ccts:Cardinality>
      <ccts:ObjectClass>Order</ccts:ObjectClass>
      <ccts:PropertyTermQualifier>Originator</ccts:PropertyTermQualifier>
      <ccts:PropertyTerm>Party</ccts:PropertyTerm>
      <ccts:AssociatedObjectClass>Party</ccts:AssociatedObjectClass>
     </ccts:Component>
    </xsd:documentation>
   </xsd:annotation>
  </xsd:element>
  <xsd:element ref="cac:Delivery" minOccurs="0">
   <xsd:annotation>
    <xsd:documentation>
     <ccts:Component>
      <ccts:ComponentType>ASBIE</ccts:ComponentType>
      <ccts:DictionaryEntryName>Order. Delivery</ccts:DictionaryEntryName>
      <ccts:Definition>associates the Order with a delivery  (or
deliveries)</ccts:Definition>
      <ccts:Cardinality>0..n</ccts:Cardinality>
      <ccts:ObjectClass>Order</ccts:ObjectClass>
      <ccts:PropertyTerm>Delivery</ccts:PropertyTerm>
      <ccts:AssociatedObjectClass>Delivery</ccts:AssociatedObjectClass>
     </ccts:Component>
    </xsd:documentation>
   </xsd:annotation>
  </xsd:element>
  <xsd:element ref="cac:OrderLine" maxOccurs="unbounded">
   <xsd:annotation>
    <xsd:documentation>
     <ccts:Component>
      <ccts:ComponentType>ASBIE</ccts:ComponentType>
      <ccts:DictionaryEntryName>Order. Order Line</ccts:DictionaryEntryName>
      <ccts:Definition>associates the Order with one or more Line
items.</ccts:Definition>
      <ccts:Cardinality>1..n</ccts:Cardinality>
      <ccts:ObjectClass>Order</ccts:ObjectClass>
      <ccts:PropertyTerm>Order Line</ccts:PropertyTerm>
      <ccts:AssociatedObjectClass>Order Line</ccts:AssociatedObjectClass>
     </ccts:Component>
    </xsd:documentation>
   </xsd:annotation>
  </xsd:element>
 </xsd:sequence>
</xsd:complexType>
<xsd:element name="OriginatorParty" type="cac:PartyType"/>
</xsd:schema>



and the Common Aggregate Schema Module (or should I say *a*
Common Aggregate Schema Module) looks like this


<xsd:schema  [ ... namespaces ... ] version="0:1-sdg">
<xsd:import namespace="urn:oasis:names:tc:ubl:CommonAggregateComponents:1:0"
schemaLocation="../../xsd/common/UBL-CommonAggregateComponents-1.0.xsd"/>
<xsd:element name="AccountsContact" type="ContactType"/>
<xsd:element name="Address" type="AddressType"/>
<xsd:element name="AddressLine" type="AddressLineType"/>
<xsd:element name="AllowanceCharge" type="AllowanceChargeType"/>
<xsd:element name="BuyerParty" type="BuyerPartyType"/>
<xsd:element name="CardAccount" type="CardAccountType"/>
...
lots more here, as much as needed
...

<xsd:complexType name="AddressLineType">
 <xsd:annotation>
  <xsd:documentation>
   <ccts:Contextualization>
    <ccts:Context>

<ccts:IndustryClassification>Small_Business</ccts:IndustryClassification>
    </ccts:Context>
   </ccts:Contextualization>
   <ccts:Component>
    <ccts:ComponentType>ABIE</ccts:ComponentType>
    <ccts:DictionaryEntryName>Address Line.
Details</ccts:DictionaryEntryName>
    <ccts:Definition>Details an unstructured line of text used for
addressing purposes</ccts:Definition>
    <ccts:ObjectClass>Address Line</ccts:ObjectClass>
   </ccts:Component>
  </xsd:documentation>
 </xsd:annotation>
 <xsd:complexContent>
  <xsd:restriction base="cac:AddressLineType">
   <xsd:sequence>
    <xsd:element ref="cbc:Line" maxOccurs="7">
     <xsd:annotation>
      <xsd:documentation>
       <ccts:Component>
        <ccts:ComponentType>BBIE</ccts:ComponentType>
        <ccts:DictionaryEntryName>Address Line. Line.
Text</ccts:DictionaryEntryName>
        <ccts:Definition>An address line of unstructured text intended for
use only by systems incapable of providing structured or fully structured
addresses</ccts:Definition>
        <ccts:Cardinality>1..7</ccts:Cardinality>
        <ccts:ObjectClass>Address Line</ccts:ObjectClass>
        <ccts:PropertyTerm>Line</ccts:PropertyTerm>
        <ccts:RepresentationTerm>Text</ccts:RepresentationTerm>
        <ccts:DataType>Text. Type</ccts:DataType>
        <ccts:Examples>&quot;123 Standard Chartered
Tower&quot;</ccts:Examples>
       </ccts:Component>
      </xsd:documentation>
     </xsd:annotation>
    </xsd:element>
   </xsd:sequence>
  </xsd:restriction>
 </xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="AddressType">
 <xsd:annotation>
  <xsd:documentation>
   <ccts:Contextualization>
    <ccts:Context>

<ccts:IndustryClassification>Small_Business</ccts:IndustryClassification>
    </ccts:Context>
   </ccts:Contextualization>
   <ccts:Component>
    <ccts:ComponentType>ABIE</ccts:ComponentType>
    <ccts:DictionaryEntryName>Address. Details</ccts:DictionaryEntryName>
    <ccts:Definition>the particulars that identify and locate the place
where someone lives or is situated, or where an organisation is
situated.</ccts:Definition>
    <ccts:ObjectClass>Address</ccts:ObjectClass>
   </ccts:Component>
  </xsd:documentation>
 </xsd:annotation>
 <xsd:complexContent>
  <xsd:restriction base="cac:AddressType">
   <xsd:sequence>
    <xsd:element name="ID" type="udt:IdentifierType" minOccurs="0"
maxOccurs="0">
     <xsd:annotation>
      <xsd:documentation>
       <ccts:Component>
        <ccts:ComponentType>BBIE</ccts:ComponentType>
        <ccts:DictionaryEntryName>Address.
Identifier</ccts:DictionaryEntryName>
        <ccts:Definition>a unique identifier given to a specific address
within a scheme of registered addresses.</ccts:Definition>
        <ccts:Cardinality>0..1</ccts:Cardinality>
        <ccts:ObjectClass>Address</ccts:ObjectClass>
        <ccts:PropertyTerm>Identifier</ccts:PropertyTerm>
        <ccts:RepresentationTerm>Identifier</ccts:RepresentationTerm>
        <ccts:DataType>Identifier. Type</ccts:DataType>

<ccts:AlternativeBusinessTerms>DetailsKey</ccts:AlternativeBusinessTerms>
       </ccts:Component>
      </xsd:documentation>
     </xsd:annotation>
    </xsd:element>
    <xsd:element ref="cbc:Postbox" minOccurs="0" maxOccurs="0">
     <xsd:annotation>
      <xsd:documentation>
       <ccts:Component>
        <ccts:ComponentType>BBIE</ccts:ComponentType>
        <ccts:DictionaryEntryName>Address. Postbox.
Text</ccts:DictionaryEntryName>
        <ccts:Definition>a post office box number or a numbered post box in
a post office assigned to a person or organization where letters for them
are kept until called for, used as part of an address.</ccts:Definition>
        <ccts:Cardinality>0..1</ccts:Cardinality>
        <ccts:ObjectClass>Address</ccts:ObjectClass>
        <ccts:PropertyTerm>Postbox</ccts:PropertyTerm>
        <ccts:RepresentationTerm>Text</ccts:RepresentationTerm>
        <ccts:DataType>Text. Type</ccts:DataType>
        <ccts:AlternativeBusinessTerms>PostBox, PO
Box</ccts:AlternativeBusinessTerms>
        <ccts:Examples>&quot;123&quot;</ccts:Examples>
       </ccts:Component>
      </xsd:documentation>
     </xsd:annotation>
    </xsd:element>

... and so on and so on ...

    <xsd:element ref="cbc:Region" minOccurs="0" maxOccurs="0">
     <xsd:annotation>
      <xsd:documentation>
       <ccts:Component>
        <ccts:ComponentType>BBIE</ccts:ComponentType>
        <ccts:DictionaryEntryName>Address. Region.
Text</ccts:DictionaryEntryName>
        <ccts:Definition>An address line of unstructured text intended for
use only by systems incapsed name for a grouping of countries, as part of an
address.</ccts:Definition>
        <ccts:Cardinality>0..1</ccts:Cardinality>
        <ccts:ObjectClass>Address</ccts:ObjectClass>
        <ccts:PropertyTerm>Region</ccts:PropertyTerm>
        <ccts:RepresentationTerm>Text</ccts:RepresentationTerm>
        <ccts:DataType>Text. Type</ccts:DataType>
        <ccts:AlternativeBusinessTerms>LocalityName, Economic
Zone</ccts:AlternativeBusinessTerms>
        <ccts:Examples>&quot;European Union&quot;</ccts:Examples>
       </ccts:Component>
      </xsd:documentation>
     </xsd:annotation>
    </xsd:element>
    <xsd:element ref="cbc:District" minOccurs="0" maxOccurs="0">
     <xsd:annotation>
      <xsd:documentation>
       <ccts:Component>
        <ccts:ComponentType>BBIE</ccts:ComponentType>
        <ccts:DictionaryEntryName>Address. District.
Text</ccts:DictionaryEntryName>
        <ccts:Definition>the name that identifies a non-administrative
division of a city, country subentity, or country, as part of an
address.</ccts:Definition>
        <ccts:Cardinality>0..1</ccts:Cardinality>
        <ccts:ObjectClass>Address</ccts:ObjectClass>
        <ccts:PropertyTerm>District</ccts:PropertyTerm>
        <ccts:RepresentationTerm>Text</ccts:RepresentationTerm>
        <ccts:DataType>Text. Type</ccts:DataType>
        <ccts:AlternativeBusinessTerms>LocalityName,
Area</ccts:AlternativeBusinessTerms>
        <ccts:Examples>&quot;East Coast&quot;</ccts:Examples>
       </ccts:Component>
      </xsd:documentation>
     </xsd:annotation>
    </xsd:element>
    <xsd:element ref="cbc:TimezoneOffset" minOccurs="0" maxOccurs="0">
     <xsd:annotation>
      <xsd:documentation>
       <ccts:Component>
        <ccts:ComponentType>BBIE</ccts:ComponentType>
        <ccts:DictionaryEntryName>Address. Timezone Offset.
Text</ccts:DictionaryEntryName>
        <ccts:Definition>the measure of time offset from UTC (Universal
Coordinated Time) for the time zone in which the address is situated. A
synonym for UTC is GMT (Greenwich Mean Time).</ccts:Definition>
        <ccts:Cardinality>0..1</ccts:Cardinality>
        <ccts:ObjectClass>Address</ccts:ObjectClass>
        <ccts:PropertyTerm>Timezone Offset</ccts:PropertyTerm>
        <ccts:RepresentationTerm>Text</ccts:RepresentationTerm>
        <ccts:DataType>Text. Type</ccts:DataType>
        <ccts:Examples>&quot;+8:00&quot; &quot;-3:00&quot;</ccts:Examples>
       </ccts:Component>
      </xsd:documentation>
     </xsd:annotation>
    </xsd:element>
    <xsd:element ref="AddressLine" minOccurs="0">
     <xsd:annotation>
      <xsd:documentation>
       <ccts:Component>
        <ccts:ComponentType>ASBIE</ccts:ComponentType>
        <ccts:DictionaryEntryName>Address. Address
Line</ccts:DictionaryEntryName>
        <ccts:Definition>Associates the address with lines of unstructured
text</ccts:Definition>
        <ccts:Cardinality>0..1</ccts:Cardinality>
        <ccts:ObjectClass>Address</ccts:ObjectClass>
        <ccts:PropertyTerm>Address Line</ccts:PropertyTerm>
        <ccts:AssociatedObjectClass>Address
Line</ccts:AssociatedObjectClass>
       </ccts:Component>
      </xsd:documentation>
     </xsd:annotation>
    </xsd:element>
    <xsd:element ref="Country" minOccurs="0">
     <xsd:annotation>
      <xsd:documentation>
       <ccts:Component>
        <ccts:ComponentType>ASBIE</ccts:ComponentType>
        <ccts:DictionaryEntryName>Address.
Country</ccts:DictionaryEntryName>
        <ccts:Definition>provides the country part of an address using a
code.  ISO3166 alpha codes are recommended.</ccts:Definition>
        <ccts:Cardinality>0..1</ccts:Cardinality>
        <ccts:ObjectClass>Address</ccts:ObjectClass>
        <ccts:PropertyTerm>Country</ccts:PropertyTerm>
        <ccts:AssociatedObjectClass>Country</ccts:AssociatedObjectClass>

<ccts:AlternativeBusinessTerms>Country</ccts:AlternativeBusinessTerms>
       </ccts:Component>
      </xsd:documentation>
     </xsd:annotation>
    </xsd:element>
    <xsd:element ref="cac:LocationCoordinate" minOccurs="0" maxOccurs="0">
     <xsd:annotation>
      <xsd:documentation>
       <ccts:Component>
        <ccts:ComponentType>ASBIE</ccts:ComponentType>
        <ccts:DictionaryEntryName>Address. Location
Coordinate</ccts:DictionaryEntryName>
        <ccts:Definition>associates the address with its location
coordinates.</ccts:Definition>
        <ccts:Cardinality>0..1</ccts:Cardinality>
        <ccts:ObjectClass>Address</ccts:ObjectClass>
        <ccts:PropertyTerm>Location Coordinate</ccts:PropertyTerm>
        <ccts:AssociatedObjectClass>Location
Coordinate</ccts:AssociatedObjectClass>
       </ccts:Component>
      </xsd:documentation>
     </xsd:annotation>
    </xsd:element>
   </xsd:sequence>
  </xsd:restriction>
 </xsd:complexContent>
</xsd:complexType>
...
and so on and so on
...
</xsd:schema>







----- Original Message -----
From: "Steven Herod" <sherod@tedis.com.au>
To: <ubl-dev@lists.oasis-open.org>
Sent: Thursday, June 17, 2004 2:04 AM
Subject: [ubl-dev] Creating a new document... where to start?


> How do people typically go about creating a new document type from
scratch?
>
> Is there a magic tool?
>
> I'm looking to assemble a new document (xsd) out of the ABIEs and Data
> Types, but I'm at a loss of how to start (do I just try and pull it
together
> in XML spy or something of the like?)
>
> Regards
> Steven Herod
> TEDIS
>
>



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