Re: SV: [ubl-dev] UBL Basics.. try "Productivity"....

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

Thanks David, for your comments.

At 2007-02-10 21:06 +1100, David Lyon wrote:
>G. Ken Holman wrote:
>>"Basics" is conformance.   I don't see how more basic you can get.
>>One cannot discount namespaces as that is the basis of global 
>>identification of information items in XML vocabularies.  This 
>>isn't just me and my beliefs or the committee's beliefs ... it has 
>>long been accepted that "basic XML" is defined by namespaces:
>Sorry to object so strongly, but it isn't.....

But I think we are talking about different things.

>Basics is getting the job done for the customer in a reasonable time 
>and for a reasonable budget....
>
>and moving up the "productivity-scale".....

Absolutely ... but not with short-term shortcuts like abandoning 
namespaces to make an instance "easier" to work with by sacrificing 
global information item identification.

>Here, we're trying to get this price-relaying thing going... so that 
>when a supplier changes the price on an item, new prices are 
>recalculated and instantly relayed onto all existing clients so that 
>they get the new price spreadsheets or files. The dealer just sets 
>the markup level, and the movement of prices up and down goes from 
>being a manual operation to an automatic thing.

Kewl!  I'm excited to see UBL used for this, and I wish that it had 
been me who had the time to create the sample UBL instances for 
you.  With the way UBL is designed, UBL information can precisely and 
unambiguously identify the information items you collect in order to 
achieve your objective.

>We all must strive to justify our existence in the business world. 
>Otherwise we get moved down the food-chain.
>
>Basics are maintaining business efficiency/productivity and aiming 
>for conformity.

Absolutely!  I have no issues with the business objectives.

>In reality, if you say you want conformance, then everybody should 
>stop working on UBL and just go buy and use office. Because that is 
>what most of the business world has decided to use en-masse. I'm 
>just calling a tree a tree and a carrot a carrot.
>
>UBL is still quite quirky and maybe still in it's infancy. I think 
>it has some way to go before it can demonstrate that it provides 
>either minor or significant productivity improvements over 
>conventional technologies that a Customer might already have access 
>to today. Correct me if I'm wrong.

Well, I think it will be vendors using UBL that will bring 
significant *productivity* improvements ... what UBL brings is 
significant *interchange* improvements.

XML doesn't *do* semantics, it only labels information in a globally 
unambiguous fashion so that users of that XML agree on what the 
labels represent and interchange information so labelled.

That applications can act on those labels and achieve global 
interchange unambiguously will bring the productivity gains.

Having expressed your pricing information in UBL doesn't 
automatically make your pricing application faster.  But I posit that 
it makes communicating your pricing information between applications 
and to the applications owned and managed by other people more 
efficient because the information is appropriately labeled so that 
all stakeholders and processes are in agreement with what the labels 
are meant to represent.

What I've been talking about in regards to "basics" and conformance 
is that some vendors or tools will short circuit the XML design to 
make their job of working with the markup somehow "easier", which 
puts the burden on users to then take that markup and translate it to 
the standard version of the markup in order to make it 
interchangeable.  The vendors are putting the work back on the 
users.  If the vendors accepted the XML design and worked with the 
specified namespaces such that all markup exposed by the applications 
conforms to UBL, then the users of those applications won't be 
burdened to use their information in the global UBL context.

But, if vendors call the XML they produce "UBL" and it isn't "UBL" 
then there will be users who won't understand the nuances and won't 
see why their UBL doesn't work with other people's UBL, and they will 
blame UBL for not working and may not think to blame the vendors who 
don't conform.

It is my opinion that UBL solves the interchange problem between 
users and systems ... it wasn't designed to make any given 
application faster ... I see its benefit as getting two applications 
to convey information faster because they both end up working from 
common ground.

Can you see, then, that your comments and mine are about two 
different issues?  I'm talking about "basics" from the interchange 
point of view, which is different from basics of application runtime 
performance.

Thanks for illuminating this distinction, David,

. . . . . . . . . . Ken

--
World-wide corporate, govt. & user group XML, XSL and UBL training
RSS feeds:     publicly-available developer resources and 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 Cancer Awareness Aug'05  http://www.CraneSoftwrights.com/u/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal