[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [ubl-lcsc] Assigning vocabulary namespaces to each document type
I've been tasked with suggesting namespace prefixes and URI strings for
each of the document types.
Unfortunately, we need this suggestion reviewed by W3C Schema experts
because I'm not sure I can just do this with impunity. I'm worried adding
a target namespace may upset the use of the shared reusable library ... can
someone please confirm that my suggestion here doesn't disturb
anything? The 0p65 library qualified the type names, but not qualifying
the type names appears to work in my tests today.
First, coming up with two-letter prefixes turned up some issues. Leaving
"po" for "Order" meant that using "or" for "Order Receipt" might be
confusing, so I looked at sometimes swapping the letters and came up with
the following prefixes:
da = Despatch Advice
in = Invoice
po = Order ("purchase order")
co = Order Cancellation ("cancellation of order")
ro = Order Response ("response to order")
rs = Order Response Simple ("response to order - simple")
ra = Receipt Advice
Remember, though, that prefixes are not important from a machine
perspective, they could be called "joe:" and "sam:" and it will still
work. But humans read them, so I thought the above might be best with what
we have. There will be many documents in the future, so I'm not sure if
I'm using something that might want to be used later, but again the same
letters could be used with different standalone document types without
being a problem.
I figured out the namespace prefixes were needed in the 0p65 schemas, but
they are not needed in the 0p70 schemas. I'm not sure why types were
prefixed in 0p65 but my tests indicate they do not need to be prefixed in 0p70.
So, in alphabetical order of the doctypes, the these follow the pattern set
out in 0p65:
<xsd:schema
targetNamespace="urn:oasis:names:tc:ubl:DespatchAdvice:1.0:0.70" ...
...
<xsd:element name="DespatchAdvice" type="DespatchAdviceDetailsType"
id="UBL500001"/>
<xsd:schema targetNamespace="urn:oasis:names:tc:ubl:Invoice:1.0:0.70"...
...
<xsd:element name="Invoice" type="InvoiceDetailsType"
id="UBL700001"/>
<xsd:schema targetNamespace="urn:oasis:names:tc:ubl:Order:1.0:0.70"...
...
<xsd:element name="Order" type="OrderDetailsType"
id="UBL100001"/>
<xsd:schema
targetNamespace="urn:oasis:names:tc:ubl:OrderCancellation:1.0:0.70"
...
...
<xsd:element name="OrderCancellation"
type="OrderCancellationDetailsType" id="UBL400001"/>
<xsd:schema
targetNamespace="urn:oasis:names:tc:ubl:OrderResponse:1.0:0.70" ...
...
<xsd:element name="OrderResponse" type="OrderResponseDetailsType"
id="UBL300001"/>
<xsd:schema
targetNamespace="urn:oasis:names:tc:ubl:OrderResponseSimple:1.0:0.70"
...
...
<xsd:element name="OrderResponseSimple"
type="OrderResponseSimpleDetailsType" id="UBL200001"/>
<xsd:schema
targetNamespace="urn:oasis:names:tc:ubl:ReceiptAdvice:1.0:0.70" ...
...
<xsd:element name="ReceiptAdvice" type="ReceiptAdviceDetailsType"
id="UBL600001"/>
I tested each of the above changes using MSV, and then with a small test
Order instance I validated the use of the Order schema and it worked as
well. I used the default namespace in the instance to the namespace above
and it validated just fine.
So I'm thinking we can get away with the change ... I certainly need it for
my stylesheets.
................... Ken
--
Upcoming hands-on in-depth Europe: February 17-21, 2003
XSLT/XPath and/or XSL-FO North America: June 16-20, 2003
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)
ISBN 0-13-065196-6 Definitive XSLT and XPath
ISBN 0-13-140374-5 Definitive XSL-FO
ISBN 1-894049-08-X Practical Transformation Using XSLT and XPath
ISBN 1-894049-10-1 Practical Formatting Using XSL-FO
Male Breast Cancer Awareness http://www.CraneSoftwrights.com/o/bc
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC