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] compatible extension of invoice following the wd-ubl-cmsc-cmguide lines-1.0


On Thu, 16 Sep 2004, Bryan Rasmussen wrote:

>>I have to do some compatible extensions to the UBL invoice. 

Interesting choice of words :)

Right now I'm not sure if the words "compatible extensions"
have come to any formal agreements within the TC yet.  The
scope of compatibility, manners of extensions, levels of
compliance, and the intricate links to methods of customizations
are some of the issues that make a quick resolution less
forthcoming than expected.

But I assume you meant that as long as you could somehow
interoperate your extended instances with UBL's published
schemas, it would be "compatible extensions" to you as far
as practicality goes.


>>Here is my understanding of what that entails:
>>
>>The process should define a new namespace, this is fine as it dovetails with
>>our requirements.

Yes, you should.   If you use exactly the same namespace values
as UBL's, it would really be a "compatible clash" of schemas.

When you do define a new namespace value, it is foreseable
that you would include some of the types or elements from
UBL's pool of entities found in CAC (Common Aggregate Components),
CBC (Common Basic Components), CCTS (Core Component Types),
UDT (Unspecialized Datatypes), SDT (Specialized Datatypes),
or even one of the 8 main documents.  

When such an inclusion is performed, it would be important
to observe the Atomic Model of Customization, where included
types and elements are treated as atomic and not modified
in any way.




>>But just in case, is it allowed that my targetNamespace is
>>one of the UBL namespaces and I just include the relevant namespace, and do
>>extensions restrictions directly to the namespace?

I don't think you would want to do that as explained above.



>>my next question is, in the context of having a new namespace:
>>
>>If I want to extend PaymentMeans this means that I will need to have an
>>{efaktura}PaymentMeans, and inside of that {efaktura}PaymentMeans I have the
>>normal PaymentMeans structure, as well as my additions, basically requiring
>>that my  extensions extend all the way up the tree if I want to just extend
>>a leaf?

I can think of two ways that you could assemble your
{efaktura}PaymentMeans type directly: you could include all the 
constituent elements withint UBL's PaymentMeans into your new
{efaktura}PaymentMeans, appending new elements below.  
This is shown below:

{efaktura}PaymentMeans {
	... element 1 from UBL's PaymentMeans ...
	... element 2 from UBL's PaymentMeans ...
	...
	<add new element:type here>
}


Or, you could include the entirety of UBL's PaymentMeans
as a sub-structure, then append new element below:

{efaktura}PaymentMeans {
	<element name="MainPaymentMeans" type="UBL:PaymentMeans" />
	<add new element:type here>
}


I hope the above pseudo-schema isn't too confusing.  :)



Best Regards,
Chin Chee-Kai
SoftML
Tel: +65-6820-2979
Fax: +65-6743-7875
Email: cheekai@SoftML.Net
http://SoftML.Net/







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