Re: Automatic Entry and Forms

>From: Mike Wexler <mwexler@frame.com>
>Why create a new tag. Wouldn't the CLASS attribute be a cleaner way of
>doing this. You could for example say:
>	<HTML>
>	<HEAD>
>	<LINK REL="Element Dictionary" HREF="http://...">
>	</HEAD>
>	<BODY CLASS="Invoice">
>	<P CLASS="Line Item"><SPAN CLASS="Item-Quantity">2</SPAN>
>	<SPAN CLASS="Item-Description">Left handed smokeshifter</SPAN>
>	<SPAN CLASS="Item-Price">$27.55</SPAN></P>
>	<P CLASS="Line Item"><SPAN CLASS="Item-Quantity">2</SPAN>
>	<SPAN CLASS="Item-Description">Skyhook</SPAN>
>	<SPAN CLASS="Item-Price">$57.55</SPAN></P>
>	</BODY>
>	</HTML>

dOh! I'm behind in reading the new specs.

Yes, using class and span is the right way to relate parts of HTML
to a data element dictionary defining semantics and relationships
to automated Electronic Commerce, etc. A new REL name can be assigned,
and the <LINK TYPE> can define the format of the referenced dictionary.

There are a couple of problems that need to be resolved. First, what
about class naming conflicts? A given form might include element definitions
from several standards, e.g. a base dictionary with name, address, etc.,
an industry specific dictionary, and an application specific dictionary.
In many cases, information exchanged is derived from data stored according
to another standard. In these cases, a data element dictionary might be
created to model the information represented by that standard.

It would be desirable to be able to distinguish Data Element classes
from other classes, e.g. styles, etc. This way "dumb" browser, i.e.
a browser that does not know how to parse a particular DED (Data
Element Dictionary) could still perform some automation based simply
on the names, e.g. the DED URL, the class name and form field name.
For example, when users retrieve a form, they could type in a few
fields, then select the "Memorize" command, and have the values stored
in a file and associated with the field name, class, and DED URL. The
user might configure an entry for auto-fill, or initialize when selected.

How can class name conflicts be resolved and how can particular classes,
IDs, or input names be identified with an element dictionary without
having to fetch and parse the dictionary?

In my prior message, I included a prefix that could relate specific
names (class, id, input-name, etc.) to a particular DED URL. What
would be the best way to provide this functionality?

JHTaylor@videodiscovery.com (Jim Taylor) writes:
: Thanks for your input. I mentioned EDI in my original proposal but no one
: responded. I spent about 3 fruitless hours of Web crawling trying to find
: out if EDI had standard field names, but all I could find were things like
: "NX01" etc.

Welcome to EDI! The fields don't have names, just numbers and a 1 line
definition. But worse, the semantics can be dependent on the context and on
other values. For example, instead of "Telephone:" and "Email:" you have
a 364 - Communication Number with a 365 - Communication Number Qualifier
set to TE or EM. The terminology and names are scrambled, but there
has been lots of work defining what information needs to be in business
forms. Thus it makes a good starting point. Unfortunately, it is biased
towards very large companies, and some data elements are missing for
consumer oriented EC.

The main thing I'd like to see in future EC standards, is a means
by which unreadable EDI data formats can be automatically translatable
into a human readable/comprehensible WWW and email format. This
would work bidirectionally.

: Any information about this, especially examples of standardized data
: element names, would be quite helpful!

Here's a quick reference:
  ftp://ftp.sterling.com/edi/sites/turiel.cs.mu.oz.au
  http://www.premenos.com/Resources/klaus/bsr.html

  http://www.premenos.com/
  ftp://ftp.sterling.com/edi/

hallam@zorch.w3.org writes:
: The approach I would like to suggest is that we simply co-opt the EDI
: templates by assigning them URIs, URN:org/iso/edi/fooo/

The EDI templates can't be directly coopted because:
  A. The meaning of a data element is often defined by the value of
     another coded qualifier.
  B. The definitions are ambiguous.
  C. Sometimes low level formatting is coded

However, it should be possible to relatively quickly transcribe the
EDI standards into a new set of untangled data element definitions
which are mappable to the EDI formats.
--------------------------------------------------------------------------
Carl Hage                                              C. Hage Associates
<email:carl@chage.com> Voice/Fax: 1-408-244-8410       1180 Reed Ave #51
<http://www.chage.com/chage/>                          Sunnyvale, CA 94086

Received on Friday, 1 March 1996 16:34:55 UTC