[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. Colts
Neck Solutions LLC -----Original Message----- HUmmm, HTML has 91 and has given birth to the endless variety of the Super 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, ;) 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]