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] Best practice for adding information to UBL entities?




> 
> " 3.4. Use of namespaces
> 
> Every customized Schema or Schema module must have a 
> namespace name different from the original UBL one. This may 
> have an upward-moving ripple effect (a schema that includes a 
> schema module that now has a different namespace name must 
> change its own namespace name, for instance). However, it 
> should be noted that all that has to change is the local part 
> of the namespace name, not the prefix, so that XPaths in 
> existing XSLT stylesheets, for instance, would not have to be 
> changed except inasmuch as a particular element or type has changed."
> 
> Have I understood this right, please see the attached image. 
> If I'm right, could someone explain how I communicate to 
> others that I'm really using e.g the original UBL Address 
> type as I don't have any reference to 
> "urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateC
> omponents-1.0". Of course, one can figure it out by comparing 
> those two, but it's not as implicit as it could be.
 
> It would be nice to "<include>" UBL CAC schema to my 
> customized CAC schema and define only the customized types 
> and element in my CAC namespace. But as I have understood it, 
> the included schema document must either define the same 
> targetNamespace as the including document or not define a 
> targetNamespace at all. 

You will have to import the UBL CAC schema into your customized CAC schema since it resides in the UBL namespace rather than including it in your customized CAC schema.  If you were to reassign the namespace of the UBL CAC schema you would break the link to the UBL standard and cause confusion as the namespace token in your set would point to a different namespace than the token in the UBL standard CAC - not a good idea.  We were very precise in designing our namespace methodology to support both the UBL standards as a consistent reliable reference point and to allow customization through declaration of customizer namespaces. For that reason you maintain the namespaces assigned to the UBL schema and make no changes to them.  Your customizations reside in their own namespaces and are easily identifiable as such.

Mark
Mark R. Crawford
Senior Research Fellow - LMI XML Lead
W3C Advisory Committee, OASIS, RosettaNet Representative
Vice Chair - OASIS UBL TC 
Chair - UN/CEFACT XML Syntax Working Group
Editor - UN/CEFACT Core Components

 
LMI Government Consulting
2000 Corporate Ridge
McLean, VA 22102-7805
703.917.7177 Phone
703.655.4810 Wireless
The opportunity to make a difference has never been greater. 

www.lmi.org 


> -----Alkuperäinen viesti-----
> Lähettäjä: Chin Chee-Kai [mailto:cheekai@softml.net]
> Lähetetty: 25. tammikuuta 2005 7:58
> Vastaanottaja: Nelson, Laird
> Kopio: UBL-Dev
> Aihe: Re: [ubl-dev] Best practice for adding information to 
> UBL entities?
> 
> Item (1) that you mentioned is a guide within UBL.  It makes 
> some suggestions, and you might read it for background.
> 
> I like your (2) suggestion better.  I can't say if this is 
> best or not best practice, but it seems the more appropriate 
> way to preserve the use of UBL component schemas, obtain 
> interoperability up to the UBL component blocks being used, 
> and yet be able to manage some form of customization on your 
> own without getting into the TC work etc.  You'd need to use 
> your own namespace obviously.
> 
> If making a profile for small businesses out of UBL is seen 
> as a form of customization, then you can read about an 
> article by Stephen Green and Ken Holman at:
> 
> "The Universal Business Language and the Needs of Small Business
> - Expressing Constraints in XML Documents to provide a Small
>   Business Profile"
> http://www.itsc.org.sg/synthesis/2004/4_UBLandSmallBiz.pdf
>  
> An intro guide together with a section on "The Implementation 
> Challenge" by Tim McGrath can be found at:
> 
> "Universal Business Language"
> http://www.itsc.org.sg/synthesis/2004/4_UBL.pdf
> 
> 
> Finally, I'll also point you to:
> 
> "Tapping Standards from Nature - Atomic Model for Creating 
> Electronic Message Schemas"
> http://www.itsc.org.sg/synthesis/2004/4_TappingStd.pdf
> 
> which describes in detail what my comments on (2) are.
> (Apologies on this self-reference, but just that the article 
> is my attempt to comment on (2) in much greater detail 
> whenever there are such similar questions or discussions)
> 
> 
> 
> Best Regards,
> Chin Chee-Kai
> SoftML
> Tel: +65-6820-2979
> Fax: +65-6743-7875
> Email: cheekai@SoftML.Net
> http://SoftML.Net/
> 
> 
> On Fri, 21 Jan 2005, Nelson, Laird wrote:
> 
> >>I am in a situation where the simple UBL order-related documents and
> >>structures *almost* fit what I want to do.  I have a couple 
> of additional
> >>fields (that's it) that I need to capture in a UBL document.
> >>
> >>What is the best practice for doing this?
> >>
> >>I see two fundamental possibilities:
> >>
> >>1.	Use some innate customization facility within UBL that I've
> >>overlooked
> >>2.	Make my own schema for my own type of document that references
> >>elements and attributes from the UBL schema, which I will 
> have to import in
> >>my schema.
> >>
> >>Am I missing anything obvious?
> >>
> >>Any pointers to pretty much anywhere related are heartily welcomed.
> >>
> >>Thank you,
> >>Laird
> >>
> 


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