- From: Paul Prescod <papresco@calum.csclub.uwaterloo.ca>
- Date: Fri, 16 May 1997 12:10:14 -0400 (EDT)
- To: jeanpa@microsoft.com (Jean Paoli)
- Cc: w3c-sgml-wg@w3.org
> 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". While I think that the idea of allowing attributes to have structure is probably a good one, I think that this is the wrong time and reason to do so. It is the wrong time because we do not have time to think it through and because SGML would have to be changed first. It is the wrong reason because we should not get in the habit of thinking of attributes as things that may be ignored and elements as things that should be "retained". Sometimes attributes should *always* be processed (for instance an ID attribute of a cross reference element). Some elements should always be surpressed. Thinking of elements as printables and attributes as unprintables moves us back into the world of thinking of documents as having a canonical visual representation -- a "correct display." In fact the correct display of a document with digital signatures may be ONLY the digital signatures if that is what the user or process is interested in. Another problem is the whole philosophy of backwards compatibility. We should not design new document types to be compatible with old applications. We should design them to be compatible with the documents that they are meant to model. If that model requires structured attributes, so be it, we'll figure out a way to add them. But as far as I can tell, there is no really hard and fast line between what an attribute should do and what an element should do so we use attributes when they are convenient (even for content) and an element otherwise (even for "metadata"). Structured attributes are not really a solution to the DTD backwards compatibility problem in most circumstances. The SGML world has two primary solutions to that problem: architectures that can transform documents conforming to one DTD into another, *in the parser*, and the DSSSL transformation language that can do the same thing in a separate process. I am not highly familiar with either yet, but we should look at those solutions to see if a simplified version might be applicable, perhaps to XML version 2.0. Paul Prescod
Received on Friday, 16 May 1997 12:10:42 UTC