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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev message

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


Subject: Re: [ubl-dev] Creating a new document... where to start?


At 2004-06-23 05:53 +0100, Stephen Green wrote:
>what I need is a way for a SBP-user to say to anyone 'I'd
>like pro-SBP
>(i.e. SBP-friendly) messages please' e.g. when sending the order - 'Please
>return
>an SBP-friendly invoice,etc'

Sure, but that is an instruction to the application that processes your 
invoice, it isn't a property of the information itself ...

I think my feelings are summed up as "how a UBL document is used is out of 
scope for a UBL document".  It is the purview of other layers and other 
protocols.  I think I believe that what an application can or cannot 
support has nothing to do with the semantics of a given transaction, so has 
no role in the data for that transaction.

I acknowledge the issue you've set forth: but it is an issue of protocol, 
not of data, isn't it?  We're only dealing with data in a UBL instance, 
aren't we?

How about an XML processing instruction?  That is, after all, what the 
objective is for a PI ... an instruction to the processing system.

A PI is an information item that is not modeled in the information 
hierarchy ... it is present in the hierarchy but it is not constrained.

What if, in UBL 1.1 we had the following:

   <!NOTATION ubl-protocol SYSTEM "urn:oasis:names:tc:ubl:protocol:1:0">
   <!NOTATION ubl-profile SYSTEM "urn:oasis:names:tc:ubl:profile:1:0">

And then in the document, we had:

   <?ubl-profile SBP?>
   <?ubl-protocol OrderResponseSimple OrderCancellation Invoice?>

An application can then interpret this as:

   "the sender of the document expects only the small business profile in 
return"

and

   "the sender of the document expects only three document types in return"

We could have a whole SC (or TC) on the protocols and signals for a UBL 
transaction, all quite independent of the UBL data.  I just think I've come 
to the conclusion that the stuff you need just doesn't belong *in* the data 
definition.

I would be mollified that you aren't corrupting the information because 
trading partners can agree all they want on all of the PI's they may need 
to successfully transact UBL information from point A to point B, without 
ever changing the meaning of the transaction data itself as validated by 
the schemas.

But I confess not to have taken very long to think about this ... I'm 
anxious to hear the thoughts of others.

>With ebXML I guess that could be in the CPA and that gets registered. This
>gives
>small businesses the means to say 'I want SBP-friendly orders' before any
>document
>gets sent.
>
>UBL does have an order response code in the order. Maybe it should have a
>general response code in every document.

But my interpretation of the order response code (just by its name) was 
that that is a property of the order response, not of the application that 
processes the order.  I see now from the Order spreadsheet the 
documentation for AcknowledgementResponseCode "specifies the type of 
Response for the Order that the Buyer requires from the Seller" ... 
interesting ... so I guess the precedent has been set and you can ignore 
what I said above.

...................... Ken

--
Public training 3 days XSLT & 2 days XSL-FO: Phoenix,AZ 2004-08-23
World-wide on-site corporate, govt. & user group XML/XSL training.
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/u/
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
Male Breast Cancer Awareness  http://www.CraneSoftwrights.com/u/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal



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