RFC: Attributes and XML-RPC

[Carsten Oberscheid]

[me]
>At 12:48 PM 09/22/99 +0200, Carsten Oberscheid wrote:
>>In a classical document markup environment, attributes are an
>>important means to separate document content from metadata.
>

[Mark Nutter]
>But when you're writing the DTD, how do you know what is "content" and what 
>is "metadata"?  For example, if you have a genealogy DTD, and you're 
>representing things like:
>
>Biological father
>Biological mother
>Location where birth certificate is recorded
>Place of birth
>Date of birth
>
>...and so on.  Which are content, and which are metadata?  It seems to me 
>that there isn't any inherent distinction, but rather an arbitrary 
>distinction is imposed by the designer at the time the DTD is written.

I was talking about "document markup" with an emphasis on (text)
*documents*, as in the fields of electronc publishing, hypertext
applications etc. There you have a very clear distinction between content
(what the document's original author wrote) and additional information
about the document's structure and/or semantics, and, yes, perhaps about
certain ways of processing (presentation, navigation etc.)

[Leigh Dodds]
>The question of whether attributes *should* be storing this kind
>of metadata seems to be another question entirely. If XML is a data format
>then why clutter XML documents with processing hints? Couldn't this
>data be captured separately in a second document and used alongside
>the first? XLinks/Pointers could be used to refer to specific elements.

Guess which constructs XLink/XPointers are implemented with? Attributes :-)
Yes, you can put attributes in elements. Yes, you can model more complex
structures with elements than you can with attributes. Yes, you can do this
in the "document markup" context as well as anywhere else. But with todays
tools it is usually easier for applications, programmers and users (e.g.
authors/editors) to tell attributes from elements than one class of
elements ("content") from another ("metadata"). Especially when the overall
system is to be kept simple. Also (at least with DTDs) you can't put
restrictions on an element's content (the character data) the way you can
restrict and validate attribute values. And DTD's is what we have today. 

Finally there's still a difference between generic meta information (even
when it's related to a certain field of processing) and entirely
application specific information. The latter (like character formatting
properties) should, even in simple environments, be kept out of the
document itself. The former (link targets, for example, or revision
information) could very well be considered an integral component of a
document -- still being distinct from the document's content. 

[Leigh Dodds, in another post]
>The 'metadata' are useful pointers to the processing application.
>They're not part of the document content, so shouldn't they be
>modelled separately? Either as element content, and make
>use of namespaces to clarify their role, or pull 'em out into a
>separate document entirely.

As long as we talk about XML as a means for generic document markup, any
generic information about a document's structure or meaning can (and
should) be modelled whithin the document's very own markup. Perhaps for XML
as a means for message interchange (yup, still know what this thread's
about...) this looks different, but I suspect the difference is only in the
information to be encoded.

.co.


---------------------------------------------- daisy bytes! ---------
 Carsten Oberscheid                                
 co at daisybytes.su.uunet.de              digital document processing
 http://www.pweb.de/daisybytes.su           electronic publishing


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)