ubl — archive

[Roberto Cisternino]

 MHonArc v2.5.0b2 -->



















ubl message






[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [List Home]








Subject: Re: [ubl] Namespace URI string implications




From: roberto@javest.com
To: "G. Ken Holman" <gkholman@CraneSoftwrights.com>
Date: Tue, 6 Jun 2006 18:15:34 +0200 (CEST)






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






Follow-Ups:

Re: [ubl] Namespace URI string implications
From: "G. Ken Holman" <gkholman@CraneSoftwrights.com>



References:

Namespace URI string implications
From: "G. Ken Holman" <gkholman@CraneSoftwrights.com>
Re: [ubl] Namespace URI string implications
From: roberto@javest.com
Re: [ubl] Namespace URI string implications
From: "G. Ken Holman" <gkholman@CraneSoftwrights.com>






[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [List Home]