Re: XHTML2 and metainformation

On Sat, 17 May 2003, Ernest Cline wrote:

> 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.

OK, but I was trying to suggest that a 'profile' and a 'namespace' are
different things and that therefore it is not a case of naming 'it' but of
naming two separate concepts (and therefore of needing two separate ways
of encoding those concepts).  A 'profile' may make use of metadata
properties taken from multiple 'namespaces'.

> What Dublin Core does with it once that
> association is established is of no interest to me.

Sure, that's fine.

> 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.

Again, that's fine... but DC examples were being used and, if, those
examples were to make it thru into the finished recommendation then it
would be good if they reflected current DCMI naming policies.

> > - 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.

Well, FWIW the reaction on the DC architecture mailing list to this
proposal seems to have been quite positive.  People seem to recognise that
the use of a period to separate a 'namespace prefix' (which is effectively
what the 'DC.' in 'DC.Date' is) is oddly different from the other main
encoding syntaxes used to carry metadata (XML and RDF/XML).

> 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.

Ah, I hadn't spotted that.  Can you explain why?

> 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.)

Sure.  I completely agree.

> > - 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.

The RFC doesn't mention it, but the working draft does, see section 2.7 of

  http://www.ukoln.ac.uk/metadata/dcmi/dcq-html/

(The profile is used to provide the URL of a human-readable document that
describes how metadata properties taken from multiple namespaces are going
to be used).

> > - 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:
> http://hades.mn.aptest.com/cgi-bin/xhtml2-issues/Meta?selectid=6217
> shows that the decision was made four months ago to put it back, it
> just hasn't yet been written into the working draft.

OK, great.  Thanks,

Andy
--
Distributed Systems, UKOLN, University of Bath, Bath, BA2 7AY, UK
http://www.ukoln.ac.uk/ukoln/staff/a.powell       +44 1225 383933
Resource Discovery Network http://www.rdn.ac.uk/

Received on Sunday, 18 May 2003 04:08:31 UTC