Re: [ubl] Namespace URI string implications

From
Ken Holman
Date
2006-06-06T12:25:00+00:00
ID
Thread
Re: [ubl] Namespace URI string implications
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: "G. Ken Holman" <>
To: "Universal Business Language" <>
Date: Tue, 06 Jun 2006 08:16:59 -0400






At 2006-06-06 11:43 +0200,  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:
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