Re: SD2 - Structured Attributes

> From: Andrew Layman <andrewl@microsoft.com>

> James asks: What is the need that structured attributes are intended to
> solve?
...
> Suppose I have a program the processes author tags such as:
> 
> <author>William Shakespeare</author>
> 
> Now somebody updates the document to a newer version, say like:
> 
> <author><first>William</first>
> <last>Shakespeare</last><DSIG>12345</DSIG><author>
> 
> What is the value of author?
> 
> If the policy is to ignore all unknown tags, the author is "William
> Shakespeare12345". If the policy is to ignore all unknown elements, the
> author is " ". 

Your two alternate policies (ignore unkown elements, or include them) come
from the browser world, and neither are common in the SGML world. And I don't
think they are appropriate to XML either, in that the data being transmitted using
XML may well be not be literature but databases.  In SGML, the mixing of 
printing and non-printing elements is very common, and the selection of 
elements to print in some circumstances, with various prefixes, or in various
orders, is equally common. 

Under your proposal, something is an element if it prints, and something is
an attribute if it does not.  This is not a workable demarcation for multiple-
target documents. 

If you specifically want to demarcate metadata, wouldn't 
<author><first>William</first>
<last>Shakespeare</last><DSIG class="metadata">12345</DSIG></author>
give you what you need, without the cost of an extra tag.

Or, better, in my opinion, is to flag it with a processing instruction
near the top of the document, e.g.: 
<?MS-structured-data meta="DSIG" ?>
or even
<?MS-structured-data  meta="DSIG"  context="author" target="MS-IE-6.*+" ?>

Using processing instructions for this would let you define a whole series
of useful behaviours without tying the data to a single application type,
and without arbitrarily assigning a "printable" semantic to elements. 
 
Rick Jelliffe

Received on Friday, 16 May 1997 04:56:00 UTC