[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: VS: VS: [ubl-dev] Best practice for adding information to UBL entities?
I'm sorry; right now I don't have time to comment all the valuable responses I got. Thus I made a new version of my "Customized Schema Dependency Model" as it shortly and unambiguously describes my thoughts. Is this the UBL compliant way to do the customization work in relation to namespaces? Please, see the attachments. I also included a PowerPoint version of this model, so any of you may share own view using the same template. (Imports of CCT, UDT, SDT and CodeList modules is been removed to keep the model simple) Additional question: Case: I don't want to customize document schema, I just want to import my own namespaces to allow use of customized components via "xsi:type". Is it UBL compliant if.. I just add those imports and change targetNamespace to my own? Or should I extend the UBL document schema to sustain the linkage? In one sense it feels rational to do the extension as I allow a use more versatile content, on the other hand it feels irrational as I'm not customizing the structure of the UBL document schema... Thanks, Juha Ikävalko TIEKE Tietoyhteiskunnan kehittämiskeskus ry TIEKE Finnish Information Society Development Centre Salomonkatu 17 A, 10th floor FI-00100 Helsinki Tel +358 9 4763 0410, Fax +358 9 4763 0399 juha.ikavalko@tieke.fi http://www.tieke.fi -----Alkuperäinen viesti----- Lähettäjä: Chin Chee-Kai [mailto:cheekai@softml.net] Lähetetty: 26. tammikuuta 2005 10:09 Vastaanottaja: Juha Ikävalko Kopio: UBL-Dev Aihe: Re: VS: [ubl-dev] Best practice for adding information to UBL entities? On Tue, 25 Jan 2005, [iso-8859-1] Juha Ikävalko wrote: >>I also have one question related to customization, more precisely >>to namespaces: >> >>" 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." I'm amazed; where did you get this paragraph from? Can I suggest to you, in such a soft voice that only you can hear, to, "Please ignore all but the first sentence." I think clarity will float once you do that. >>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:CommonAggregateComponents-1.0". >>Of course, one can figure it out by comparing those two, but >>it's not as implicit as it could be. Looking at your nicely laid-out diagram, logically, if modifying UBL's original CBC and CAC is what you intended, then the bottom-most "UDT" and "SDT" should be "CBC" and "CAC" respectively. You can also consider adding 3 more self-directed arcs on MyCBC, MyCAC and "Document Schema Module" blocks, with each of their edges named, for example, "mycbc", "mycac", "dsm" respectively. Thus, this means each block defines and uses these 3 new prefixes. Yes, this also means the existing "cbc" and "cac" prefixes on your current diagram should be renamed "mycbc", "mycac". The "dsm" would then be defined with a targetNamespace value that is different from UBL's namespace value. What happens inside MyCBC and MyCAC blocks would be more interesting. >>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. Yes, I know what you mean. You can do that easily in a customized spreadsheet environment, not through XSD mechanisms. You can perform customized spreadsheet by duplicating the contents of the appropriate UBL spreadsheet, modifying the contents in exactly the manner you mentioned above. This avoids problems brought up by momentary namespace value clashes. Then, you could generate the customized schemas from the customized spreadsheet using any appropriate tool that re-targets the generated namespace value to your new namespace value (as defined for "dsm" above). Best Regards, Chin Chee-Kai SoftML Tel: +65-6820-2979 Fax: +65-6743-7875 Email: cheekai@SoftML.Net http://SoftML.Net/ >>Juha Ikävalko >>TIEKE Tietoyhteiskunnan kehittämiskeskus ry >>TIEKE Finnish Information Society Development Centre >>Salomonkatu 17 A, 10th floor >>FI-00100 Helsinki >>Tel +358 9 4763 0410, Fax +358 9 4763 0399 >>juha.ikavalko@tieke.fi http://www.tieke.fi >> >> >>-----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: >> >> >>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 >>>> >>
customized_schema_dependency_model_v2.png
Customized Schema Dependency Model_2005-01-26.ppt
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
