[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl] Namespace URI string implications
Hello thank you for the answer, I am sorry when I assert something or make a questions please understand I could miss something from past discussions, I am new to this. I think the namespaceURI is the right way to identify a new version or a new information item, but about keeping the documentElement namespaceURI across UBL versions I get a little worried. The filter-before-validation is a good solution to let the previous scene work but I understand it works on new items only, what about overridden ones (changed version) ? I understand that an UBL cross-version compatibility could be nice the price should not be the complexity. I remember UBL promise is to be a simpler, stronger solution than past B2B standards, I think complexity could exclude both little softwarehouses and customers. I still think the best way is to give the instruments to easyly upgrade UBL versions (XSLT) and have a precise namespaceURI for each document. When business partners agreements are configured with a precise UBL version why they have to change ? They should upgrate both to a newer version I think. Thank you, it is just my opinion. Best regards UBL ITLSC Chair Roberto Cisternino > At 2006-06-06 11:43 +0200, roberto@javest.com wrote: >>my name is Roberto Cisternino (ITLSC chair). >>I woult like to give my opinion about this matter. > > Thank you! > >>One of the main reasons UBL is better than past EDI formats is the >>validation which is made possible using a precise WXS Schema based on >>unique namespaces aware of UBL versions. >> >>e.g. urn:oasis:names:specification:ubl:schema:xsd:Invoice-1.0 >> >>I think an UBL document "instance" should be based on a precise namespace >>URI, then inside the schema there could be a sofisticated re-use of >>components by choosing from 1 or more component collections still >>versioned and identified by a precise namespaceURI. > > Do you have a comment regarding only using a new precise namespace > for those information items that are subsequently added to a document > model? > >>In a different way I think it could be hard or impossible to make generic >>software able to deal with different UBL versions and to transform them >>successfully in case of a technology update. > > I have done this in a complete stylesheet of fifteen XSLT > instructions (which includes error checking!). An example is in the > paper I am preparing. > >>Maybe there could be a sort of deprecation system, this way an UBL 2.0 >>interface could be able to read UBL 1.0 automatically by following >>deprecation instructions... just an idea (could be heavy) > > I believe it would not be heavy if we base the deprecation on the > simple concept of the namespace of an information item. > >>We had versions using EDIFact or X12 but the translation between versions >>was hard as documents were often invalid. > > I believe this would not be the case for namespace-based processing. > >>XSLT transformation is a possibility, but maybe a free UBL update service >>(web service) could be a "must". > > I'm glad you would be willing to consider XSLT and I hope that you > find the descriptions in my paper of value. The filtering stylesheet > would be supplied by UBL as part of a support package or even along > with the schemas. More detail is coming in the paper. > > . . . . . . . . . . . Ken > > -- > Registration open for XSLT/XSL-FO training: Wash.,DC 2006-06-12/16 > Also for XSL-FO/XSLT/XML training: Birmingham, UK 2006-07-04/13 > Also for XSL-FO/XSLT training: Minneapolis, MN 2006-07-31/08-04 > Also for XML/XSLT/XSL-FO/UBL training: Varo,Denmark 06-09-25/10-06 > World-wide corporate, govt. & user group UBL, XSL, & XML training. > G. Ken Holman mailto:gkholman@CraneSoftwrights.com > Crane Softwrights Ltd. http://www.CraneSoftwrights.com/o/ > Box 266, Kars, Ontario CANADA K0A-2E0 +1(613)489-0999 (F:-0995) > Male Cancer Awareness Aug'05 http://www.CraneSoftwrights.com/o/bc > Legal business disclaimers: http://www.CraneSoftwrights.com/legal > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. You may a link to this group and all your TCs in > OASIS > at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > Roberto Cisternino
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]