OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-lcsc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: [ubl-lcsc] RE: [ubl-ndrsc] Updated UBL Library --> shorter Tagnameswihtin B usiness Document s

Great work Gunther.  These tag names are nice.

As for the issue you raise about BBIEs -- I don't believe there is any
problem, nor do I believe there is any work to be done.  The global element
declarations now present in the document-level namespaces (e.g.
"urn:oasis:names:tc:ubl:Order:1.0:0.70") are just fine as they stand.  I
don't think we should go putting "dummy ABIE rows" into the model at this
point in the game.

I do see a couple further issues with namespaces though.  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

While I don't feel too strongly about #3, I fear that #1 (and the consequent
#2) are more serious issues.  I can't do the namespace calculus in my head
to determine if this violation will cause UBL instance documents to look
different then they otherwise might -- but I suspect it will.

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.  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?  But I won't be able to do
that easily right?  I may be way off here, someone please let me know if I
am.  Otherwise we need to repair.


-----Original Message-----
From: Stuhec, Gunther [mailto:gunther.stuhec@sap.com] 
Sent: Friday, January 24, 2003 12:03 PM
To: 'ubl-lcsc@lists.oasis-open.org '; 'ubl-ndrsc@lists.oasis-open.org '
Subject: [ubl-ndrsc] Updated UBL Library --> shorter Tagnames wihtin
Business Document s

Hello all, 

according the telephone call with Marion Royal, i changed the perl script in
that way that the tag names within the business document schemas are shorter
now (without Object Class Terms). You'll find the new package as an attached

All elements within the complex type of this schemas refers to the
equivalent global declared element within the reusable type, if this element
already exists. Or otherwise it generates a new global declared element in
each business document schema, if this not exists as a global declared
element in the reusable types schema. 

Therefore, all business document schemas does have some global declared
elements for BBIEs, like: Note, DeliveryDate, LanguageCode etc. My
suggestion is that we put all this BBIEs into the spreadsheet of reusable
types. This BBIEs must be defined in the spreadsheet under a dummy ABIE row.
Otherwise, my perl-script doesn't recognize this BBIEs. 

If someone will doing this update in the reusable types spreadsheet, please
do it as soon as possible, because a have an internet-connection until 4:00
pm, today. After than, I will be on the way back home. And I guess, I can
connect into the Internet on Saturday.

Kind regards,


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC