In a message dated 95-08-18 15:21:51 EDT, [log in to unmask] (Joe English)
>I'm not sure that HTML needs this particular wheel.
I totally disagree. I believe HTML and electronic commerce are on a direct
collision course. I would much rather start embracing electronic commerce now
than to try to retrofit it into an incompatible system later.
>A really sophisticated browser might let the user click on a
>chunk of text tagged as a date and display a localized version,
>or maybe even send a message to the user's appointment calendar,
>but that's about the limit of what an HTML agent could do. Even
>a task as simple as "sort this list by date" would be
>near-impossible, since HTML doesn't enforce a strict enough
>structure for such tasks to be meaningfully and unambiguously
Again I disagree. The browser I am working on explicitly supports things like
"sort this list by date". In the future most HTML documents will be generated
by programs or in HTML aware editors. Hand coding of HTML tags will
ultimately disappear. Nobody hand codes RTF even though it is possible to do
it - people use RTF aware editors instead.
>> A simple SGMLfied EDI encoding
>> <QTY><S02 VALUE="3.25">3.25<S03 VALUE="MR">meters</QTY>
>> <DTM><S01 VALUE="002">Delivery is requested by<S02 VALUE="951001">October
>> first before<S03 VALUE="1900">7:00PM<S04 VALUE="ED"></DTM>
>Hmm... with this scheme, an HTML user agent would
>have to understand quite a bit about EDI in order
>to know that the <S02> element in the second example
>represents a date and that the <S02> in the first example
>represents a quantity. So would HTML authors, for that
The dumb user agent doesn't need to know anything about the EDI tags; it
justs ignores them shows the text. On the other hand, more sophisticated
user agents can do complex indexing and processing on the document. Wasn't
this the whole idea behind SGML?
The scheme could be extended to encode the element type on the tag.
<QTY><S02 EL=380 VALUE="3.25">3.25<S03 EL=355 VALUE="MR">meters</QTY>
But this doesn't really gain you anything. You need to have a copy of the
EDI database if you are going to manipulate the document and the mapping from
<QTY><S02> to EL380 is in the database - why needlessly copy around a piece
of constant information. Note - you can't just use EL380 as a tag since the
tags can be repeated.
>What is the advantage of this scheme over:
> <p>Delivery is requested by <date value="1995-10-01">October
> before <time value="19:00 EDT">7:00 PM</time>?
EDI is an approved ISO/ANSI standard. EDI has already specified over 500
date/time qualifiers. It has a universal means of specifying timezones. It
supports things like qualified date ranges, for example a sales promotion
that starts on Oct1 and ends on Oct10. Date/time is a very simple case; there
are much large gains when other things like products and prices are
Basically the EDI people have done our homework for us and I want to
piggyback off from their work. There is nothing to be gained be reinventing
methods to encode date/time, quantities, measurements, geographic locations,
name/address or hundreds of other common things.
>I can see where the former would be useful if the
>document were to be submitted into an order-tracking
>database or the like, but it does not seem likely that HTML
>will be used for such purposes.
I think you are very wrong on this point. There are hundreds of shopping
malls on the net. Hasn't the name Netscape Commerce Server given you a clue
to their direction?
Jon Smirl, [log in to unmask]