- From: Ernest Cline <ernestcline@mindspring.com>
- Date: Sat, 19 Apr 2003 16:53:38 -0400
- To: Toby A Inkster <tobyink@goddamn.co.uk>, www-html@w3.org
Toby A Inkster wrote: > On Fri, Apr 18, 2003 at 02:02:15PM -0400, Ernest Cline wrote: > | > Actually there isn't a problem if you follow this draft: > | > > | > Expressing Qualified Dublin Core in HTML/XHTML meta elements > | > http://www.ukoln.ac.uk/metadata/dcmi/dcq-html/ > | > > | > Because a link rel is used to indicate the namespace: > | > > | > <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/" /> > | > | This is a kludgy hack that assumes that Dublin Core has exculsive use > | of <link rel="schema.DC" /> and <meta name="DC.*" />. > > See section, 2.6 of the article linked above. 'DC' is an arbitrary > string. The following are to be considered equivalent: > > <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/" /> > <meta name="DC.date" content="2000-01-01" /> > > -and- > > <link rel="schema.DUBLIN" href="http://purl.org/dc/elements/1.1/" /> > <meta name="DUBLIN.date" content="2000-01-01" /> > > -and- > > <link rel="schema.FLIBBLE" href="http://purl.org/dc/elements/1.1/" /> > <meta name="FLIBBLE.date" content="2000-01-01" /> > > The 'DC' in 'DC.date' (or the 'FLIBBLE' in the third example) is just a > reference to the URI with rel 'schema.DC' (or 'schema.FLIBBLE') -- like > an ID/IDREF pair in XML -- the actual ID used is irrelevent (although it > is probably sensible to use a mnemonic one such as 'DC' or 'DUBLIN') as > long as it is applied consistantly. It still is a kludgy hack. Not as kludgy as I first thought, but still kludgy. Dublin Core assumes that <link rel="schema.*" /> can be used to assign a namespace to a metainformation schema. This however is not a normative part of the XHTML2 standard nor has it ever been a normative part of any (X)HTML standard issued by W3C. (Dublin Core was briefly mentioned informatively in the HTML 4 standard.) RFC 2731 is an IETF standard, but it was not issued by W3C, applies to HTML only, and other uses of <link> and <meta> that conflict with it are still valid HTML documents. 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. However, tools that extract or make use of metainformation would have to be rewritten for XHTML2 anyway because of the change from <meta content="The Value" /> to <meta>The Value</meta>. Clearly, maintaining backward compatability with the methods used by Dublin Core in the past has been ignored already. 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.
Received on Saturday, 19 April 2003 16:53:44 UTC