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: FW: [ubl-dev] looking for practical examples

You are comparing apples and oranges.


HTML has zero content-oriented "data elements," because it is all about presentation. As you described, HTML has been successful, while being kept fairly terse, but that is possible because it is a formatting utility. Setting flags for "bold" or to invoke frames is not payload "content." http://www.w3.org/TR/REC-html40/index/elements.html


Further, HTTP has only four verbs ("methods" – get, post, put, delete and head – head being a variant of get), and these are transport oriented> Like HTML, HTTP is indifferent to the particularities of "content."


The efforts of those working on the Semantic Web, the evolutionary "next step" to address "content" may be making progress, but it is hard sledding because machines are stupid.


"Non-standardized" use of XML has been successful because it can be used to associate payload "data" with descriptive "tags" rather than requiring users (and automated processes) to scamper around for "metadata" to figure out, for example, what a comma delimited file actually contains. It is very helpful for machine-to-people communications, because people are smart and are likely to comprehend the tags if the document is appropriately rendered. Unfortunately machines are just as stupid as ever and do not "comprehend" either the tags or the payload data.


UBL is playing in the machine-to-machine "standard XML" transaction space, which is why it is closer to real world content particularity. It is still abstracted from the excruciating level of particularity of internal systems content although those implementing translation (UBL to internal or vice versa) are often overwhelmed with particularity.


In the b2b world, if you create your own version of an "invoice," with sensible, conformant XML, in a b2b environment your non-standard XML invoice transaction will not flow through automated accounts payable processes. You may therefore not get paid at all or will be forced to rekey your invoice data into a customer portal, because companies are shutting off "non-automated" payment processes.


With UBL compliance at both ends of the trading relationship, the customer can receive, translate, import, validate and pay your invoice with no human intervention, presuming that your tags and associated content align with the customer's translation process and the customer's automated accounts payable process and content. That process also supplies content essential to the customer's "payment advice" process. A very bad situation is to receive money, but not be able to apply the cash to the right customer account and invoice. Not only must transactions be "standardized," but transactions need to chain together coherently.


With respect to the UBL "catalog" transactions, these are indeed discrete transactions and are part of the b2b transaction chain. In the predecessor transaction, a customer initiates a terms and conditions contract or master order to acquire a certain subset of items from, say, an office supply company or from a second-tier supplier for parts used in manufacturing or maintenance. The customer may then require that the supplier send a "catalog" of the products, parts and services associated with the agreement, often with customer specific prices and perhaps customer-specific descriptions or part numbers. (It is bad karma if the customer does not ask for that "catalog" data, because in all likelihood orders and release orders will be plagued by data quality problems). The supplier's processes import at least portions of the "catalog" data into the customers internal ERP, manufacturing, maintenance system or standalone inventory systems, usually with the "catalog" never to be seen in its native form. Also, the supplier creating the UBL catalog transaction may not source the "catalog" information from the supplier's own online sales catalog, but instead source that data from the supplier's ERP, product data management, sales system or some combination.


As to your comment "who can predict every business model," that is not much of a challenge, because there are no new business models, only new implementations of old ones. Somewhere in the archeological trove of un-translated cuneiform tablets there probably is one saying "I won't pay a bill rendered in hieroglyphics and base 60 arithmetic" New technologies have increased geographic reach, add new products and services, cut B2B transaction costs, made dynamic what had to be static, but without creating new business models.



                                                Fulton Wilcox

                                                Colts Neck Solutions LLC



-----Original Message-----
From: Alexander Whillas [mailto:whillas@gmail.com]
Sent: Monday, February 16, 2009 10:21 AM
To: ubl-dev@lists.oasis-open.org
Subject: Re: [ubl-dev] looking for practical examples




HUmmm, HTML has 91 and has given birth to the endless variety of the

Super Information Highway. With HTML they didn't try to predict every

semantic, every possible document that someone would want to create

with it. That would be silly, also it would mean that every time there

was a new type of document the spec would have to be revised.


91 elements, such a small set, has also been the reason it was so

successful, that is, it was easy to learn. There is a general

principle here: language specifications (like emails, Fulton old sport

;) are more likely to be read (and responded to) the sorter they are.


Or following that principle: "Less is More". When designing a

language, or anything really, elegance of design is in simplicity.



>> The ideal design for a transaction-oriented environment such as UBL is one

>> "document" per action verb (e.g., to buy, to ship, to receive, to invoice,

>> to pay, etc.).


I disagree. One document _instance_ per transaction not a new document

necessarily. A Catalogue is still a Catalogue across transactions. Its

describing the same things which should be described the same way, its

use is implied by the nature of the trabnsaction, it doesn't have to

be implicit in the transaction.


When I (or anyone) requests a Catalogue, say via a RESTful protocol,

both the sender and the receiver _already know_ who they are. It

doesn't have to be implicit in the document as well (i.e. every

webpage doesn't an identifier for the server and one for my web

browser embedded in it. Its implied in the request protocol).


I think UBL should be more general than having a different document

for each step in an implied business process, for who can predict

EVERY business model that needs to use it?



>> Presumably UBL configuration tools can help users check off

>> the fields available and relevant to the transaction.


AHhhh, but what if its not a user using the XML (heaven forbid) but

software translating from a Relational Scehma to a message format and

then back again. XML is _not_ a User Interface nor should it be used

to generate one.




This email is already too long :)



To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org

For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org

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