[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-dev] Questions about UBL customization
----- Original Message -----
From: "Arianna Brutti" <ariannabrutti@yahoo.it>
To: <ubl-dev@lists.oasis-open.org>
Sent: Thursday, June 16, 2005 2:00 PM
Subject: [ubl-dev] Questions about UBL customization
> Hi ubl-dev,
>
> I have some questions about UBL customization ... I
> hope someone can help me.
>
> QUESTION 1:
>
> In "Guideline for The Customization of UBL v1.0
> Schema" there is the following example (it's about the
> use of Ur-Type):
>
> <xsd:complexType name="MyPartyType">
> <xsd:restriction base="ur:PartyType">
> <xsd:sequence>
> <xsd:element ref="PartyIdentification"
> minOccurs="0" maxOccurs="0">
> </xsd:element>
> ...
> </xsd:sequence>
> </xsd:restriction>
> </xsd:complexType>
>
> where the PartyType definition is the following:
>
> <xsd:complexType name="PartyType">
> <xsd:sequence>
> <xsd:element ref="PartyIdentification"
> minOccurs="0" maxOccurs="unbounded">
> </xsd:element>
> ...
> </xsd:sequence>
> </xsd:complexType>
>
> My question is:
>
> Why the restriction has been applied on Ur-Type and
> not on UBL type?
>
> The element PartyIdentification is optional in
> PartyType definition ... therefore I thought it was
> possible doing that:
>
> <xsd:complexType name="MyPartyType">
> <xsd:restriction base="cac:PartyType">
> <xsd:sequence>
> <xsd:element ref="PartyIdentification"
> minOccurs="0" maxOccurs="0">
> </xsd:element>
> ...
> </xsd:sequence>
> </xsd:restriction>
> </xsd:complexType>
>
I think it's a typo. I expect the authors meant PartyType
to have
<xsd:element ref="PartyIdentification"
minOccurs="1" maxOccurs="unbounded">
But whatever the reason, you are correct
that you would only need to use an ur:xyzType
when XSD derivation rules prohibit 'base="abc:xyzType"'
I expect this needs correcting in the spec
>
> QUESTION 2
>
> In "Guideline for The Customization of UBL v1.0
> Schema" is written:
>
> For each of the context drivers the following
> characteristics should also be specified with
> reference to its value:
>
> CodeListID
> CodeListAgencyID
> CodeListAgencyName
> CodeListName
> CodeListVersionID
> languageID
> CodeListUniformResourceID
> CodeListSchemeUniformResourceID
> Content
> Name
>
>
> My question is:
>
> How can I do that? How can I specify these
> information?
>
> I have the following idea ... but I'm not sure that is
> right:
>
> <xsd:annotation>
> <xsd:documentation>
> <ccts:Contextualization>
> <ccts:Context>
> <ccts:Geopolitical CodeListID="http://...";
> CodeListAgencyID="..." ...>
> France</ccts:Geopolitical>
> </Context>
> </ccts:Contextualization>
> </xsd:documentation>
> <xsd:annotation>
>
I don't think it was intended that UBL 1.0 actually cater
for this - rather I think it has been anticipated for UBL 2.0.
It was envisiaged that by UBL 2.0 there would be clarity over
the possible mechanism for catering for contexts to be used
with UBL.
It may be that the extra attributes will be added to UBL 2.0's
parameters schema so it would be best, I would suggest, to
wait to see if that happens over the coming weeks. Someone
is looking into the UBL 2.0 customization methodology and
I brought up the need for its inclusion in 2.0 at the last TC
meeting.
I do think you are spot on with the structure though. Then in
the parameters schema we might have something like:-
<xsd:complexType name="ccts:Geopolitical">
<xsd:simpleContent>
<xsd:extension base="xsd:normalizedString">
<xsd:attribute name="codeListID" type="xsd:normalizedString"
use="optional"/>
...etc
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
The main thing is though, we'll need suitable codelists.
>
> QUESTION 3
>
> Should I create a new schema for my definitions of
> types (derived from UBL types)?
>
If you use UBL 1.0, adding your own types can, I believe,
be achieved with derivation of UBL types using non-abstract
customisation groups. This was concluded as an side issue
to the issue of UBL minor versioning in a UBL working group
led by Arofan Gregory (I hope he doesn't mind my mentioning
him here as the main architect of this proposal). Though there
hasn't yet been complete agreement about UBL itself using the
technique for minor versions (though it was the sort of design
always envisiaged from the early days of UBL with regard to
its use of polymorphic, type awareness in XSD schemas) and
its application to customisation is also yet to be approved for
UBL 2.0, we viewed this method as being quite appropriate
for both versioning and customising.
You create a schema like this:
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns="my:namespace:CustomAggregateComponents-1.0"
xmlns:ccts="urn:oasis:names:specification:ubl:schema:xsd:CoreComponentParame
ters-1.0"
xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponent
s-1.0"
xmlns:xyz="my:namespace:CustomBasicComponents-1.0"
... other namespaces as necessary (such as UBL codelists, your own codelists
and your own datatypes) ...
elementFormDefault="qualified" attributeFormDefault="unqualified"
version="minor">
<xsd:import
namespace="urn:oasis:names:specification:ubl:schema:xsd:CoreComponentParamet
ers-1.0"
schemaLocation="http://docs.oasis-open.org/ubl/cd-UBL-1.0/xsd/common/UBL-Cor
eComponentParameters-1.0.xsd"/>
<xsd:import
namespace="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponent
s-1.0"
schemaLocation="http://docs.oasis-open.org/ubl/cd-UBL-1.0/xsd/common/UBL-Com
monBasicComponents-1.0.xsd"/>
<xsd:import
namespace="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateCompo
nents-1.0"
schemaLocation="http://docs.oasis-open.org/ubl/cd-UBL-1.0/xsd/common/UBL-Com
monAggregateComponents-1.0.xsd"/>
<xsd:import namespace="my:namespace:CustomBasicComponents-1.0"
schemaLocation="MyCustomBasicSchema.xsd"/>
... other imports as necessary (such as UBL codelists, your own codelists
and your own datatypes) ...
<xsd:element name="Something" type="SomethingType"
substitutionGroup="cac:Something"/>
<xsd:complexType name="SomethingType">
<xsd:complexContent>
<xsd:extension base="cac:SomethingType">
<xsd:sequence>
<xsd:element ref="xyz:SomeNewID" minOccurs="0" maxOccurs="1"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:schema>
And in your custom basic components schema you have something like
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns="my:namespace:CustomBasicComponents-1.0"
xmlns:ccts="urn:oasis:names:specification:ubl:schema:xsd:CoreComponentParame
ters-1.0"
xmlns:udt="urn:oasis:names:specification:ubl:schema:xsd:UnspecializedDatatyp
es-1.0"
xmlns:sdt="urn:oasis:names:specification:ubl:schema:xsd:SpecializedDatatypes
-1.0"
... other namespaces as necessary (such as UBL codelists, your own codelists
and your own datatypes) ...
targetNamespace="my:namespace:CustomBasicComponents-1.0"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xsd:import
namespace="urn:oasis:names:specification:ubl:schema:xsd:CoreComponentParamet
ers-1.0" schemaLocation="UBL-CoreComponentParameters-1.0.xsd"/>
<xsd:import
namespace="urn:oasis:names:specification:ubl:schema:xsd:UnspecializedDatatyp
es-1.0"
schemaLocation="http://docs.oasis-open.org/ubl/cd-UBL-1.0/xsd/common/UBL-Uns
pecializedDatatypes-1.0.xsd"/>
<xsd:import
namespace="urn:oasis:names:specification:ubl:schema:xsd:SpecializedDatatypes
-1.0"
schemaLocation="http://docs.oasis-open.org/ubl/cd-UBL-1.0/xsd/common/UBL-Spe
cializedDatatypes-1.0.xsd"/>
... other imports as necessary (such as UBL codelists, your own codelists
and your own datatypes) ...
<xsd:element name="SomeNewID" type="IdentifierType"/>
<xsd:complexType name="IdentifierType">
<xsd:simpleContent>
<xsd:extension base="udt:IdentifierType"/>
</xsd:simpleContent>
</xsd:complexType>
</xsd:schema>
The document schema can be similarly extended (here from the UBL 1.0
Invoice) but here there is a minor problem (see below) -
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns="my:namespace:Invoice-1.0"
xmlns:in="urn:oasis:names:specification:ubl:schema:xsd:Invoice-1.0"
xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponent
s-1.0"
xmlns:xyz="my:namespace:CustomBasicComponents-1.0"
xmlns:abc="my:namespace:CustomAggregateComponents-1.0"
... other namespaces as necessary ...
targetNamespace="SomeDocumentMinor"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
version="minor">
<xsd:import
namespace="urn:oasis:names:specification:ubl:schema:xsd:Invoice-1.0"
schemaLocation="http://docs.oasis-open.org/ubl/cd-UBL-1.0/xsd/maindoc/UBL-In
voice-1.0.xsd"/>
<xsd:import namespace="my:namespace:CustomBasicComponents-1.0"
schemaLocation="MyCustomBasicSchema.xsd"/>
<xsd:import namespace="my:namespace:CustomAggregateComponents-1.0"
schemaLocation="MyCustomAggregateSchema.xsd"/>
... other imports as necessary ...
<xsd:element name="Invoice" type="InvoiceType"
substitutionGroup="in:Invoice">
<xsd:annotation>
<xsd:documentation>Some documentation</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:complexType name="InvoiceType">
<xsd:annotation>
<xsd:documentation>Some documentation</xsd:documentation>
</xsd:annotation>
<xsd:complexContent>
<xsd:extension base="in:InvoiceType">
<xsd:sequence>
<xsd:element ref="xyz:SomeNewID" minOccurs="0" maxOccurs="1"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:schema>
The problem doing this in UBL 1.0 is that there are some locally declared
elements
(IDs and Codes) in the document schemas. This means that instances for
derived,
customised documents need prefixes for such elements where none were needed
in the
UBL 1.0 instances. This is expected to be fixed in the next release of UBL
which
will have all elements in documents declared globally. Then you'll hopefully
get a
more satisfactory effect in customised document instance. When they are
viewed
by derivation handling software the handling of the extensions is as
desired.
>
> QUESTION 4
>
> Do customized schemas examples exist? If yes, where
> can I find them?
See above for now. Maybe others are creating better ones. Sweden's
SWEInvoice has something slightly different and is worth a comparison
http://lists.oasis-open.org/archives/ubl/200504/msg00102.html
I understand further work on the customisation of UBL is in the pipeline
(from our danish colleagues).
All the best
Stephen Green
>
>
>
> Excuse me for my bad English and thanks for your
> interest.
>
> Bye
>
> Arianna Brutti
>
>
>
>
>
>
>
> ___________________________________
> Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB
> http://mail.yahoo.it
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]