Re: What are the problems with IDML?

>>> Doug Donohoe <donohoe@emerge.com> 08/22/96 09:47am >>>
>
>So, yes, I agree that META could be used to instantiate the
>IDML data model.   And yes, you can write a robot to understand
>this format.
>
>However a couple of open questions:  
>
>	1) Which would you prefer to write as a user (after all, 
>	   it's the user we're trying to help!)?
>	2) Which would you prefer to parse as a robot writer [1]?

Give me break! The very important decision on how to design a standard
is determined by whether it takes someone 2 hours instead of 2.1 hours
to write a parser?? Pasting meta tags together is absolutely trivial, and
(as has been pointed out) people writing this stuff will have tools to help
them do it, so both of these arguments are without merit.

There are more important considerations (some of which have already
been pointed out).

1) Product information (with more than one product in a document) is not
metainformation so it doesn't belong in meta tags, and in any case it
couldn't be put there without some dorky numbering/id system
  <META NAME="ID-PRODUCT_NAME#1" VALUE="Jacks">
  <META NAME="ID-PRODUCT_NAME#2" VALUE="Ball">

2) Why go to all the trouble of duplicating information (product name,
description, price, etc.) that may already be in the document in
human-readable form?

3) Some of the IDML information is already provided by de-facto META
tags. Admittedly, these aren't terribly standardized, but why bury useful
information about the publisher, location, phone number, etc. in IDML tags
when it could be standardized and shared via meta tags used by many
different robots/agents/whatever.

4) If there really are merchants with 600,000 products to catalog, surely
they don't want their product information scattered over hundreds or
thousands of documents buried in META or ID tags. IDML should use the
established HTML hyperlink mechanism instead of reinventing it with a
"url-redirect" attribute.

5) (Related to point 4) Why should browsers be slowed down by
plowing through ID tags that have little to do with content and nothing to
do with presentation?

Suggestions:

IDML is already broken into four groups. Three of these groups
(publisher, info, system) contain meta information that probably belongs
in META tags or separate documents. This is information such as
publisher name, location, keywords, robot instructions, etc. Since IDML
has proposed specific formats for these, then all that's required is a meta
tag identifying the document as IDML compliant, thus vouchsafing that
information in the meta tags is in the format expected by an IDML parser.
Then the information is also available to other parsers that look at meta
tags.

The fourth IDML group consists of product information. This really can't
be shoehorned into meta tags, but instead of making way too many new
attributes, the IDML guys could create classes. This allows a number of
things to work nicely. Span tags could be used to identify existing text:
  <span class="id-product-name>A Hard Day's Night</span> 
  <span class="id-product-description>Released on CD in 1988.</span>
  $<span class="id-product-price>13.47</span>

(Is this a misuse of span?)

Non-visible information such as currency, keywords, etc. could still be
contained in IDML tags. Obviously many people will want all the
information stored in one place.  Instead of using the very goofy
"url-redirect" attribute, they should use the established id attribute to
identify each product (in place of the part-number attribute) and then put
a link element in the header:

  <link rel="IDML" href="whatever">

This is a quick spew at the end of a very long day, so it may not be
coherent or well thought out, but it's certainly more consistent with
established standard ways of doing these things than the current IDML
proposal.

______________________________________________
Jim "The Frog" Taylor, Director of Information Technology
<mailto:jhtaylor@videodiscovery.com>
Videodiscovery, Inc. - Multimedia Education for Science and Math
Seattle, WA, 206-285-5400 <http://www.videodiscovery.com/vdyweb>

Received on Saturday, 24 August 1996 00:03:17 UTC