[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]