RE: Units of Measure

[Arofan Gregory <arofan.gregory@commerceone.com>]

Stephanie:

I absolutely envision scenarios where (particularly) small suppliers receive
an XML document over the wire, and use a simple application to present the
document as a web form that they would respond to. The web form is nothing
more than an XSL style sheet, with some forms controls embedded for sending
back an acceptance of the order, for example. Also, a similar program would
take XML, present a "blank" PO (as described at run-time by schema or DTD)
and present it in a browser for Order creation using XSL to represent it as
a form. I know of at least two companies that are looking toward this kind
of functionality to build products.

In fact, many more sophisticated server-side technologies based on XML use
XSL as a basic way to do presentation, without benefit (or the overhead) of
a transformation process more suited to mapping code lists. Such
applications generally look at the transformation capabilities of documents
(PO -> POResponse, for example).

The easier you make ebXML-compliant documents work with XSL, the easier it
will be for everybody to implement, but the major point here is that XSL is
very poor at content translation, and an intuitive code can be presented
directly. This is a limitation of XSL, granted, and one of my least favorite
things about it, but the XML tools community has overwhelmingly adopted at
as the major presentation technology for XML.

I understand your point - no one generally reads "raw" XML - but they *do*
read XML that has been subjected to no more than an XSL style-sheeting.

Cheers,

Arofan 

-----Original Message-----
From: COOPER,STEPHENIE (HP-PaloAlto,ex1)
[mailto:stephenie_cooper@hp.com]
Sent: Monday, July 10, 2000 3:48 PM
To: ebXML Core
Subject: RE: Units of Measure


The struggle I have with Arofan's suggestion that there's a category "(2)
Small- and Medium-sized enterprises' businesspeople, who might not have the
benefit of translation software, and merely look at the business messages in
a browser or other simple presentation format" is that I and some of my
colleagues are struggling to think of a realistic, real life scenario where
these folks would actually need to read raw XML.  The key word here is
"realistic".

Does someone have some examples of realistic situations in which a business
person is going to have a need to read raw XML without benefit of something
that transforms it for viewing?  When would raw XML be the only choice
presented?  Who would do the presenting?  Would you ever have someone who is
creating raw XML and presenting it someone who must read the raw XML?  

Right now, if I can present something to a partner either via a phone call,
fax of a printout, or raw XML with perfectly readable text used throughout,
that partner is likely to tell me "forget the XML - call me or send me the
fax."  I have yet to experience the situation of someone presenting me with
raw XML as the only choice.

I'm sure most folks agree that we don't want an XML that's as abstract as
X12 and EDIFACT.  I certainly don't have the ultimate answer.  However, I do
have a gut feeling that machines are going to do most of the reading, so if
we have make a tradeoff I'd advocate a solution that is slightly less
person-friendly in order to make it less likely to be misinterpreted by a
machine.

-----Original Message-----
From: William J. Kammerer [mailto:wkammerer@foresightcorp.com]
Sent: Monday, July 10, 2000 2:10 PM
To: ebXML Core
Subject: Re: Units of Measure


Stephenie Cooper, of HEWLETT-PACKARD, asked "Have we defined the 'human'
in 'human-readable'? Who is going to read raw XML?  What category of
human?"

I added "it's reasonable to expect the reader to be an expert in the
problem domain if they're really going to read [an] XML document."  By
this definition, XML documents based on OTA or RosettaNet - the two
frameworks I picked on earlier - are readable: anybody who is an expert
in the problem domain with a few hour's overview of XML (e.g., begin
tags and end tags and well-formedness) will be able to make out most of
the message content.

The same is definitely not true of EDI, X12 or EDIFACT:  the segment
tags may be mnemonic, but even EDI experts have a hard time remembering
which positional element does what in the segment(s).  And there's no
way a problem-domain expert (travel agent), who otherwise only has the
vaguest notion of EDIFACT, would be able to read interactive EDI
messages for the Travel, Tourism and Leisure biz.  But they would be
able to understand a good part of an OTA customer profile message, even
without access to the OTA Message Specifications!   And OTA, like I said
before, does use codes, albeit spelled out as in "Childrens Services and
facilities" (for one of the many possible values for Hotel.PropAmenity)
rather than small mnemonic tags.

This "readability," which EDI clearly does not possess, is obviously a
good part of XML's appeal for B2B messaging.  EDI is perceived to suck,
somewhat because people "generally find pure codes daunting," as Arofan
Gregory suggests.  If only it were that easy: the problems with business
integration will remain after the hype dies down. After we enter the
trough of disappointment, are we going to be left with people reading
raw XML documents, handkeying the data into their order entry systems,
much as they do with rip-n'-read EDI today?

William J. Kammerer
FORESIGHT Corp.
4950 Blazer Memorial Pkwy.
Dublin, OH USA 43017-3305
+1 614 791-1600

Visit FORESIGHT Corp. at http://www.foresightcorp.com/
"Commerce for a New World"