[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]