[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: FW: [ubl-dev] looking for practical examples
2009/2/16 Fulton Wilcox <fulton.wilcox@coltsnecksolutions.com>: > You are comparing apples and oranges. The orchid defence! This is obviously not true about "physical" form: 1. Subsets of the XML specification 2. Both Markup languages that follow the same markup rules. Removing these 2 commonalities there is only tag names left and thus we are in sphere of "semantics". Yes HTML's domain is "Publishing" while UBL's domain is "Business". I'm not disputing that, I'm disputing the "design philosophy" behind UBL as opposed to HTML. (I am NOT suggesting UBL use HTML elements because the domain of information is different). > HTML has zero content-oriented "data elements," because it is all about > presentation. Firstly, if you don't think there is any "data" in a HTML document please explain the Google and their business model bsed on their popular search engine. This has given rise to (see SEO: http://en.wikipedia.org/wiki/Search_engine_optimization). Secondly, I'm guess you haven't been keeping up with whats going on in the HTML world for the last 6-8 years, have you. If you read the intro to the specification you have referenced: "Style sheets simplify HTML markup and largely relieve HTML of the responsibilities of presentation." (see: http://www.w3.org/TR/REC-html40/intro/intro.html#h-2.3.5) Also see www.csszengarden.com for proof of this concept (particularly the markup). Finally, I would say that HTML is _all_ content oriented these days. The saying on the web is: "Content is king". > As you described, HTML has been successful, while being kept > fairly terse, but that is possible because it is a formatting utility. Ya, but all mark-up languages are "formatting utility[s]". CSV is a formatting utility. RSS is a formatting utility. They are for formatting data within their domain. I'm suggesting the revise of your statement: because its a formatting utility it was kept terse and hence was successful. The obvious principle: Simple things are easier to use than complex ones and hence more readily adopted. The Tim McGrath example (thanks Ken) is funny because even a developer of UBL found it easier to roll his own than use UBL :) > Setting flags for "bold" or to invoke frames is not payload "content." No, your right but thats just one of 3 functions it fulfils (in my eyes): 1. Content markup as in the "stronger emphasis" <strong></strong> ("bold"ing has been phased out in favour of semantic description mainly because HTML is not about presentation but semantic markup and also it doesn't translate to other written scripts the same way). 2. Demarkation of sections of content, which may or may not be used by CSS to produce different layouts on different machine readers. 3. Application interfaces via Forms. And all this with only 91 elements. > 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." Exactly my point! Because operational transactional information about the movement of data is not related to the data. The end user doesn't know or care about the HTTP headers when they are reading a webpage, its not within the domain of the mark-up i.e. "Publishing" just as it it not in the domain of Business ether. There IS a separation of the "dumb" program from the content it deals with. > 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. Oh yeah, the "Semantic web" (what every that means) is almost as successful as UBL :) The reason being it hasn't evolved out or piratical need, from industry, but from academia. The classic "hammer before the nail" situation. > "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. YES, XML is for people-to-machine communication, as are all markup languages, programming languages etc as michines like binary and humans like ASCII. There should be easy for Humans to read. Its not really. NO, if a document is "appropriately rendered" (much debate about this) people actually have no idea about the tags look like or which are used. Visual Broswing is an "application" of mark-up and its only in combination with Application does anything take meaning (semantic or otherwise). The markup alone is not semantic, only in combination with a Web Browser application does it take on meaning, or when a Search Engine indexes it. As with UBL the programmer of one system has to agree with that of another what the meaning of each data chuck is for. The UBL standard makes this process easier and that is its only function. Outside of this there is no "semantic" just ascii. > Unfortunately machines are just as stupid as ever and do not "comprehend" > either the tags or the payload data. Ja, but humans write programs (i.e. programmers of business systems) and the are the ones who do the "comprehend"ing. Computers will never "comprehend" anything no matter how you mark it up. > UBL is playing in the machine-to-machine "standard XML" transaction space, > which is why it is closer to real world content particularity. Humm, if really was machine-to-machine, it would be binary, like the stuff coming down the data connection you are using to receive this email. XML is for humans. If you think anything in XML is close to "real world data" I think your living in a (digital) fantasy world. I think HTML comes close(r) to this than UBL because it doesn't imply as many constraints on the data model. Hell, the original question I asked here demonstrates that UBL is not interfacing with reality too well and its completely within the computer domain (a subset of reality). > 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. wOT? > 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. Ya, as is the reality at the moment, thought out the world, everywhere. > 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. And yet, somehow, people are still getting paid? > With UBL compliance at both ends of the trading relationship... Oh look a digital unicorn! Quickly if we catch it we might be able to ride it to Utopia! (I think thats where Marx is living). > With respect to the UBL "catalog" transactions, these are indeed discrete > transactions and are part of the b2b transaction chain. Oh, _The_ B2B Transaction Chain. I hope I get a chance to see _it_ one day. > 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. OK... who can predict every new "implementation" of the "old" business models? > 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" I'm sure there is not because the fundament rule of ALL business is that the sell wants the money and the customer wants the product (I'm not sure if they had "bills" in those days). This is why business has managed without UBL so far. > ... cut B2B transaction costs... Yes, this is the ONLY practical function UBL can possibly have. If it fails at this by making implementation costs too high or transaction slow (unwieldy documents compared to competing ideas) then it fails it only function and will be swept aside in a Darwinistic manor as is predecessors where (http://www.unimaze.com/on+ubl.aspx).
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]