Re: Automatic Entry and Forms

hallam@w3.org ("Phillip M. Hallam-Baker") writes:
: A simple mechanism for automatic entry of data into forms is described. This
: mechanism permits clients to support an arbitrary number of competeing
: schemes.
: 
: One approach to this problem would be to define a set of common field
: identifiers which would be recognised by the browsers. These would have to
: be distinguished in some way to avoid unintended confusion e.g. <input
: name="$date-of-birth">.
: 
: It is proposed that an additional attribute TEMPLATEis added to the HTML
: <FORM> tag. This takes as its parameter a URI which identifies the template
: used.
: 
: <FORM TEMPLATE="http://www.w3.org/template/default">
: Your name:    <input name=name>
: Date of Birth <input name=date-of-birth>
: </FORM>

I've been advocating something very similar on the bit.listserv.edi-l
and other EDI related lists. EDI (Electronic Data Interchange) is
a grandiose name that really means computer-computer messaging for
automated business transactions. Basically EDI means messaging using
ANSI X12, ITU EDIFACT, or similar standards.

What you really want is a way to standardize the names of fields and
thier semantics so you don't have 10,000 different templates. The EDI
standards have sort of defined standard fields, called "data elements",
used for a wide variety of business transactions. I believe it is possible
to leverage off this work to come up with standard "templates" as used
above.

There are lots of problems with the EDI standards, and I don't have time
to discuss the topic in detail here, but I will collect more information.
Basically, the EDI standards are designed for fully automated mainframe-
mainframe communications. The standards aren't really standards, they are
suggestions customized by each user. Programmers modifiy thier code to
accomodate each other trading partner. The terminology is incomprehensible
to an average business person or layman, and you need to hire an EDI
consultant to interpret the standard. The architecture of the data format
looks like something out of the card punch era, and programming is a
nightmare.

There are a number of standards efforts going on involving "Data Element
Dictionaries", essentially ways to standardize field (data element) names
and semantics. I'll have to defer to later a more complete set of
references. The BSR (Basic Semantic Repository) is a new effort meant to
move the EDI standards forward, with a database of standardized terms,
data elements, and relationship to the EDI standards. Terms are based on
normal business language. References to a BSR could be a way to solve the
problem of making sense of the fields common across lots of templates.

I think it would be useful to tag information anywhere in an HTML page,
not just fields of a form to be returned. The tagging would associate
information in a page with the definition in a Data Element Disctionary.
This might be used by WWW robots "agents", or by WWW browsers enhanced
for auto-interactive Electronic Commerce. For example, maybe you want
to find a restaurant that is open at 10:00pm on Sunday. If restaurant
web pages had a way to tag "Hours of Service" in thier web pages, then
software could extract this information and build an index.

What I suggested before on the EDI-L list, was to add a couple of tags,
e.g. <DELEMDICT href="http://..." prefix="x12po-">, and
<DELEM name="x12po-order-amount">. The idea is that a DELEMDICT allows
a set of data element names to be imported to be associated with
a form field name, or a set of data tagged with <DELEM>...</DELEM>.
It might also be useful to associate definition list and table entries
with a data element definition.

The prefix allows multiple Data Element Dictionaries (DEDs) to be
referenced in the same page. For example, there might be an ISO
standard DED, an informally developed standard, and a company specific
dictionary.

The URL referenced would conform to some sort of standardized format which
would be human and machine readable. By appending a field name to the DED
URL, e.g. http://www.itu.ch/bsr/edifact/98b/orders/order-amount, then
information on the definition of a field would be available for viewing
or automated processing.

Of course SGML could be used directly in lieu of the <DELEM>, etc. However
it would not be easy to distinguish the data element tags from other
SGML tags, and browsers would need to access and analyze a DTD.

: The TEMPLATE URI is used as an index only. It names a semantic binding of
: input tag name attributes. It is not necessary for the client to know the
: semantic binding, it is only necessary to differentiate one binding from
: another.

The URI could be both a unique name for "dumb" browsers, or could be
a live reference to a database for more automated processing.

: On encountering a from with a template URI a client would look up the URI in
: a database to see if it had encountered it already. If so the fields in the
: form would then be filled in using the stored defaults.

A really simple extension to a browser would be to have a side file with a
set of "URI field-name value" data which the user can edit. When a form is
displayed with the URI reference, the default values will be inserted
automatically. If there were a simple format defined then files could be
shared across browsers and blank forms could be downloaded and inserted.

A more elaborate browser might have a "memorize" button, which would
insert into the side file the values typed after the form was loaded,
associated with the URI and field names. Presumably the browser would
display the information to be inserted and ask for confirmation.

An even more sophisticated browser could fetch the DED referenced by the
URI, then correlate the data elements on the page to an interface
with an EDI front-end.

: It may be desirable to permit template attributes to be defined for
: individual fields rather than the form as a whole.

Using a unique field name prefix allows arbitrary combinations rather
than a per form basis.

: Discussion.
: 
: The sceheme described would permit personal defaults to be specified for
: arbitrary forms. The usefullness of a defaulting scheme would be limited by
: its userbase. Hence it would be expected that most form designers would
: choose to follow a single standard even though the specification does not
: enforce this.

My hope is that the standards the develop would be compatible (from a
conversion point of view) with the existing and future EDI/EC standards.
I don't think this needs to be complex (as are the EDI standards), and
simple solutions very close to the TEMPLATE proposal are possible.

I don't have time to respond fully at this time, but I would be interested
in collaborating in the future.

: Certain communities may wish to develop their own, highly specialised
: conventions. In particular companies may have internal conventions. In some
: cases the designer of a form may wish to use a specialised binding in order
: to avoid ambiguity problems.

Sounds like EDI. What is missing from EDI is a good methodology for
precisely defining the definitions and exchanging them in a computer
readable form along with relationships to other standards. Such a
methodology is beginning to develop.
--------------------------------------------------------------------------
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 Tuesday, 27 February 1996 17:02:38 UTC