Re: XHTML2 and metainformation

Ernest Cline wrote...

> Let me first quote from an earlier post of mine on this subject, since
> its been almost a month since it was made:
>
> # If RFC 2731 is to be adapted so as to be part of XHTML2, then it
> # should be referenced normativly in the recommendation.  Currently
> # it has only a mention as part of an unreferenced example in the
> # Metainformation Module.
> #
> # Clearly a method of associating metainformation with a
> # schema/profile SHOULD be standardized in XHTML2 and incorporated
> # as part of the Metainformation Module.  The chosen method is of
> # secondary importance.
>
> # There are three methods I see of doing this in XHTML. One would be a
> # minimal rewriting of RFC 2731 so as to adapt it to syntax of XHTML2.
> #
> # This would look something like:
> #     <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/" />
> #     <meta name="DC.Date">2000-01-01</meta>
> # Another would be similar to RFC 2731, but instead of link would use a
> # new element defined in the Metainformation Module and look something
> # like this:
> #     <schema name="DC" profile="http://purl.org/dc/elements/1.1/" />
> #     <meta name="DC.Date">2000-01-01</meta>
> # The third would be like my initial proposal:
> #     <ml profile="http://purl.org/dc/elements/1.1/">
> #       <mi name="Date">2000-01-01</mi>
> #     </ml>
> # Of these three formats, I really don't like the first as I think that
> # associating metainformation with its schema is a task that should not
> # be left to <link> but should have its own element. I have a slight
> # preference for the third format, but would have no complaints if
> # something like the second format were incorporated into XHTML2.
> # Leaving the association of metainformation with its schema to a
> # non-W3C extension is in my opinion totally unacceptable. Even
> # sanctioning the first format above and making it normative would be
> # preferable.
>
> At the time of that discussion, no mention was made of the desirability
> of using a schema to specify new link types for use with <link> or <a>.
> If such an ability is desirable then I agree that the third format
> I gave is insufficient.  Of the two remaining formats, I'd prefer
> something like the second where a specific element such as <schema> for
> making that association is used instead of doling that job off to
> <link>, especially if one of the jobs of the this method is to assign
> possible linktypes for <link> to use. Elements that could modify their
> own interpretation make me suspiscious.

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.

In any case, it is worth noting that

- all DC element names start with a lower-case letter (i.e. date rather
  than Date)

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

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

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

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 Saturday, 17 May 2003 15:50:07 UTC