Re: SD2 - Structured Attributes

It seems to me this proposal is redundant with namespaces.  As Lee has pointed
out obliquely, if there is that must structure, then it should be an element.
 In the case given here, can't we say that XML-DSIG is in the security
namespace. If I'm not interested in security, I'll know I can ignore it.
 Alternatively we can have a means for declaring that certain elements extend
other elements, and whether the extension is transparent or not (in this case
it is - the extension can be ignored if you don't know about it).

I suspect this'll only get support if you can find a compelling example which
is almost impossible through less radical means.

Matthew Fuchs
matt@wdi.disney.com

On May 15,  9:14pm, Jean Paoli wrote:
> Subject: SD2 - Structured Attributes
> SD2 - Structured Attributes:
> ----------------------------------------
>
> XML uses containment to hold data between tags. This data can be
> internally
> subdivided, for example the author can be marked to indicate internal
> parts, as
> in <AUTHOR><LAST>Dantzig</LAST>, <FIRST>Tobias</FIRST></AUTHOR>. These
> divisions
> don't change the contents of AUTHOR, them merely identify constituent
> parts.
>
> Contrast this with adding a digital signature, as in the following:
> <AUTHOR
> XML-DSIG="ABCDE">Dantzig, Tobias</AUTHOR>. Here, the signature is an
> attribute
> of the author element, that is, supplementary information, but not
> actual
> contents: Adding a signature does not change who the author is. The
> distinction
> between contents and attributes is important when tools (particularly
> down-level
> versions of products) need to process data without fully understanding
> its
> meaning: unknown attributes are completely ignored, while the contents
> of
> unknown elements are retained. In both cases above, an uninformed tool
> could
> retrieve the value of AUTHOR as "Dantzig, Tobias".
>
> However, XML attributes inside the tag cannot have structure, nor can
> they
> themselves have attributes, nor can they be easily extended.
> Consequently, for
> example, a digital signature cannot have any structure (except by
> private
> conventions and private syntax) nor can attributes be digitally signed.
> The
> current attribute syntax is insufficient.
>
> Proposal: I'm going to say something radical here: We should invent a
> way to add
> structure and attributes to attributes. A special character sequence
> "<*" in an
> opening tag (the exact characters used are to-be-determined) signals
> that the
> contents are an attribute, not a subdivision.
>
> <ORDERS>
> 	<LINEITEM XML-ID="L1" >
> 		<NAME>Number, the Language of Science</NAME>
> 		<AUTHOR><First>Dantzig</>, <Last>Tobias</>
>
> <*XML-DSIG><DIGEST>5432109876</><SIGNER>AdamB@microsoft.com</></XML-DSIG
> >
> 			</AUTHOR>
> 		<PRICE>5.95</PRICE>
> 		<AVAILABILITY>Out of Stock</AVAILABILITY>
>
> <*XML-DSIG><DIGEST>1234567890</DIGEST><SIGNER>AndrewL@microsoft.com</></
> XML-DSIG>
> 		</LINEITEM ></ORDERS>
>
> In this example, the AUTHOR element has a digital signature attribute,
> as well
> as subelements for First and Last parts of the name. Similarly, LINEITEM
> has a
> digital signature. Finally, the digital signatures themselves have
> subelements,
> one of which has a attribute, XML-TYPE.
>
> An attribute that identifies an element should be expressed within the
> element's
> tag. (That is, the XML-ID attribute.) All other attributes can be
> expressed in
> either form, so there is a smooth upgrade path as structural needs show
> up. The
> grove will reflect both syntactical representations the same way.
>
>
> -----------------------------
>
>-- End of excerpt from Jean Paoli



--

Received on Friday, 16 May 1997 13:44:44 UTC