[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: FW: [ubl-dev] looking for practical examples
I guess someone else suggested you use XML then :-) 2009/2/17 Alexander Whillas <whillas@gmail.com>: > 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). > > --------------------------------------------------------------------- > To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org > > -- Stephen D. Green Document Engineering Services Ltd http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]