RE: [ubl-lcsc] Further namespace issues

["Burcham, Bill" <Bill_Burcham@stercomm.com>]

Here's the changes I made by hand:

To the top-level element in UBL_Library_0p70_Reusable.xsd I added:

 targetNamespace="urn:oasis:names:tc:ubl:CommonAggregateTypes:1.0:0.70"
xmlns="urn:oasis:names:tc:ubl:CommonAggregateTypes:1.0:0.70" 
xmlns:cat="urn:oasis:names:tc:ubl:CommonAggregateTypes:1.0:0.70"  

To the top-level element in e.g. UBL_Library_0p70_Order.xsd I added:

xmlns:cat="urn:oasis:names:tc:ubl:CommonAggregateTypes:1.0:0.70"  

Then I added a child:

	<xsd:import
namespace="urn:oasis:names:tc:ubl:CommonAggregateTypes:1.0:0.70"
schemaLocation="UBL_Library_0p70_Reusable.xsd"/>

When I went to validate that schema it became apparent that some of the
qnames now needed qualification (since Aggregate types from the Reusable
module were now explicitly in their own namespace). 

Element ref value "AllowanceCharge" became "cat:AllowanceCharge".
"BuyerParty" -> "cat:BuyerParty"
"Contract"-> "cat:Contract"
"DeliveryTerms" -> "cat:DeliveryTerms"
...and many others -- you get the idea -- basically every ref to an element
defined in cat:.

Then I asked XML Spy to generate an Order.  It qualified each element.  I
changed that doc so as to use "cat:" as the default namespace -- and removed
the qualification so the instance looks nicer (see attachmenet).

I had to doctor that doc a little, adding:

/n:Order/OrderLine/DeliveryRequirement/DeliverySchedule/DeliveryRequirement
(apparently, Spy doesn't handle the recursive definition
DeliverySchedule->DeliveryRequirement->DeliverySchedule...)

/n:Order/OrderLine/OrderedShipment/TransportEquipment/TransportEquipmentMeas
urement/TransportEquipment
(again, a recursive definition was involved
TransportEquipment->TransportEquipmentMeasure->TransportEquipment...)

The attached zip contains the generated Order instance (default namespace is
"cat:" so only the Order elements are explicitly qualified) -- I think it's
elegant enough (80/20 !!).  Also included are the hand-doctored Order and
Reusable schemas.

I can doctor the other schemas if I must -- my preference would be to make
one last (!) tweak to the Perl.


-----Original Message-----
From: Jon Bosak [mailto:Jon.Bosak@sun.com] 
Sent: Friday, January 24, 2003 3:22 PM
To: gkholman@CraneSoftwrights.com
Cc: ubl-lcsc@lists.oasis-open.org; ubl-ndrsc@lists.oasis-open.org
Subject: [ubl-lcsc] Further namespace issues


(Copying to ndrsc to make sure everyone sees this... The former subject line
was something like "Re: [ubl-lcsc] RE: [ubl-ndrsc] Updated UBL Library -->
shorter Tagnames wihtin Business
Documents")

Ken's second form is clearly prettier for the stylesheet writer.

Key questions for NDR and interested observers:

1. Does this disturb NDR's current plan of record for global
   naming?

2. Can the change be accomplished simply and easily by hand?
   (Gunther is on his way back to Walldorf now and has to be
   considered unavailable for the time remaining to finalize the
   schemas.)

Jon

==================================================================

Date: Fri, 24 Jan 2003 16:05:39 -0500
From: "G. Ken Holman" <gkholman@CraneSoftwrights.com>
Subject: Re: [ubl-lcsc] RE: [ubl-ndrsc] Updated UBL Library --> shorter
 Tagnames wihtin B	usiness Document	s
To: UBL LCSC <ubl-lcsc@lists.oasis-open.org>

At 2003-01-24 14:40 -0600, Burcham, Bill wrote:
>I do see a couple further issues with namespaces though.

Well spotted, Bill!

>Don't know how
>critical these are -- I'd love to hear some NDRSC opinion here.
>
>1. The "Reusable" schema defines no target namespace at all, whereas 
>our specification says it should define a namespace of the form 
>"urn:oasis:names:tc:ubl:CommonAggregateTypes:[TBD version info]" 2. As 
>a result, higher-level namespaces that rely on "Reusable" have no way 
>of declaring that reliance.  For instance, I would expect to see a 
>namespace prefix declaration in the "Order" namespace referring to 
>"Reusable" -- also an "import" element. 3. Our specification says that 
>the "CoreComponentTypes.xsd" schema should define a namespace of the 
>form "urn:oasis:names:tc:ubl:CommonLeafTypes:[TBD
>version info]" but instead it defines 
>"urn:oasis:names:tc:ubl:CoreComponentTypes:1.0:0.70".
>...
>Just intuitively (best I can do right now) let's think about a 
>(reusable) component like an Address (woo hoo -- my favorite!).  If I 
>have an address deep inside an Order document, won't the Address tags 
>be in the Order namespace?  And if I have an Address deep inside an 
>Invoice, won't the Address tags be in the Invoice namespace?  That 
>breaks reuse.

Yes, between documents it does.  In my stylesheets I was only trying to 
address reuse within the one given stylesheet but you are right (by 
extension) that in my current design the reusable bits are localized to 
each document type.  I could not have a single XSLT template for Address 
shared across all of the stylesheets.

>I need to be able to say something like:
>
><xsl:template match="ubl:Address">...do something smart...</...>
>
>And have that work on Orders and Invoices right?

That is certainly doable, and would make stylesheet *fragments* shareable 
across all document types.

The instance would read either as follows:

   <Order xmns="..Order.." xmlns:ubl="..CommonLeafTypes..">
     ...
     <ubl:BuyerParty>
       ...
       <ubl:PartyName>
         ...
       <ubl:Address>
         ...

or more compactly as:

   <po:Order xmns:po="..Order.." xmlns="..CommonLeafTypes..">
     ...
     <BuyerParty>
       ...
       <PartyName>
         ...
       <Address>
         ...

by using the default namespace for the reusable constructs.

I can accommodate this change in my stylesheets very easily, Bill, if it is 
accepted.

...................... 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


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

Attachment: sample-order-generated.zip
Description: Binary data