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?
Use a hierarchical name space:
	<LINK NAME="ISO999999" REL="Element Dictionary" 
           HREF="http://www.iso.org/...">
	<SPAN CLASS="ISO999999.partNo">

> 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. 
Actually the beauty of the idea is that they aren't separate. Lets say
that some auto-parts store creates a really dull page, but uses classes
to specify auto-fillin. I can then create a style sheets that makes all
the part numbers red, underlined, and blinking in order to spiff things up
a bit. If we have two reasons why people need to do descriptive markup, and
they both use the same syntax, this might help encourage people to "do
the right thing."

> 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.
It could do that even if the class names were put in their for other
purposes (like style sheets).

> 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.
> 
>

Received on Friday, 1 March 1996 17:13:12 UTC