[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: RFC: Attributes and XML-RPC

  • From: Carsten Oberscheid <co@d...>
  • To: <xml-dev@i...>
  • Date: Wed, 22 Sep 1999 20:56:35 +0200

attributes of a father
[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@d...              digital document processing
 http://www.pweb.de/daisybytes.su           electronic publishing


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i...
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@i... the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)



PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.