W3C home > Mailing lists > Public > www-html@w3.org > May 2003

Re: XHTML2 and metainformation

From: Ernest Cline <ernestcline@mindspring.com>
Date: Sat, 17 May 2003 21:02:24 -0400
To: www-html@w3.org
Message-ID: <3EC6A360.25974.C823E8@localhost>

Andy Powell wrote:

> It'd be good to try and find a way to involve the DCMI (in particular the
> DCMI Architecture WG at http://dublincore.org/groups/architecture/ ) in
> your discussions about embedding DC metadata in XHTML 2.  In particular,
> you might be interested in the DCMI Working Draft at
>   http://www.ukoln.ac.uk/metadata/dcmi/dcq-html/
> I'd certainly be interested in your comments on this document.  The
> current intention is to move this document, or a version of it, thru the
> DCMI Recommendation process.

First off, let me point out that my interest is as far as meta-data is 
concerned is limited to ensuring that there is a standard method in 
associating the meta-data with its profile/schema/namespace/whatever 
the heck you want to call it.  What Dublin Core does with it once that 
association is established is of no interest to me.  The RFC 2731 
mechanism is fairly good but suffers in my opinion from two problems.  
One is the fact that valid HTML documents can ignore it, therefore 
limiting its usefulness as a standard.  A lesser problem is that it 
relies on <link> instead of an element of its own to make that 
association.   Since meta-data methods can make use of <link> as well 
as <meta> for establishing meta data, that leads to potential conflicts 
that should be avoided.

> In any case, it is worth noting that
> - all DC element names start with a lower-case letter (i.e. date rather
>   than Date)

What DC does with its element names should not be a concern for XHTML. 
As far as XHTML is concerned, DC could choose to use UPPERCASE, 
CamelCase, or lowercase, or be case insensitive.  I used DC.Date rather 
than dc.date in my example simply because that is what the version of 
the DC standard I used recommended.

> - it seems sensible to move to a syntax that more closely mirrors the
>   encoding of DC in XML and RDF/XML (i.e. dc:date rather than DC.Date)

Seems more like marketing than practicality to me.  Switching to a 
colon instead of a period does not gain any new functionality and does 
make backwards compatability more difficult.  Also, continuing to use 
periods instead of switching to colons would seem to me to make the 
task of writing ECMAScript or Java that interacts with meta-data 
slightly easier.  However, the issue of the character(s) used to 
separate a meta-data namespace from its associated meta-data element 
when they are used together in the name attribute of the XHTML <meta> 
element would seem to me to be an issue for the XHTML standard to 
address rather than for Dublin Core (or any other meta-data standard) 
to address.  Unless the XHTML standard addresses this issue then it is 
possible for two different methods of associating meta-data to both be 
valid XHTML while conflicting with each other.  (Granted, this concern 
is largely theoretical, but since it can be easily dealt with, it 
should be.)

> - it is not clear to me that it is sensible to re-use DCMI namespace URIs
>   (e.g. http://purl.org/dc/elements/1.1/) to identify 'profiles' - a
>   profile (at least as far as I understand it) may want to use metadata
>   properties from multiple namespaces.  Keeping these things separate is
>   akin to the  separation of XML namespace URIs and XML schema URIs.

As far as I can see in the DCMI standards, I don't see any current use 
being made of the profile attribute. RFC 2731 and the working draft you 
refer to only bother to specify the DCMI namespaces via the
<link rel="schema.*" /> mechanism.

> - DC applications currently use the scheme attribute of the HTML
>   meta element (see the document above).  It'd be good not to lose this
>   attribute (or an equivalent) in XHTML 2.

While it is not in the current working draft, A look at:
shows that the decision was made four months ago to put it back, it 
just hasn't yet been written into the working draft.
Received on Saturday, 17 May 2003 21:03:07 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:06:03 UTC