- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Fri, 17 Apr 2009 12:34:27 +0200
- To: "Sean B. Palmer" <sean@miscoranda.com>
- CC: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>, www-archive <www-archive@w3.org>
Sean B. Palmer wrote: > § 4.2. > > “Applications that don't merit a registered relation type may use an > extension relation type, which is a URI [RFC3986] that uniquely > identifies the relation type.” > > Why not use reversed domain names? For example: > > Link: <http://example.org/>; rel=index; > rel="start net.example.rel.other" > > The advantage is brevity. Since the specification also says that > clients SHOULD NOT dereference the URIs identifying the relation > types, it doesn't seem to matter that the extension type be a URI, > except for consistency with the URI forms of the registered relation > types. > ... The disadvantages are: - potential ambiguity when domain ownership changes (which, when using URIs, can be worked around by choosing a different scheme), - the requirement to actually have a domain name available for that use, and - incompatibility with RDF properties and Atom link relations. > § 5. > > “[...] It is semantically equivalent to the > <LINK> element in HTML, as well as the atom:link feed-level element > in Atom [RFC4287].” > > Doesn't this mean that HTML user agents will have to support the following? > > <meta http-equiv="Link" value='<style.css>; > rel="stylesheet"; type="text/css"'> I don't think it means that, at least not according to the HTML specification. > Why burden HTML user agents in this way? Could you specify that Link > has no meaning when used in conjunction with meta/@http-equiv in HTML? It seems that clarifying the use of meta/@http-equiv is something the HTML WG should do. > “Here, the second link has a title encoded in UTF-8, uses the German > language ("de"), and contains the Unicode code point \u'00E4' ("LATIN > SMALL LETTER A WITH DIAERESIS").” > > \u'00E4' is a character, not a code point. A code point in Unicode is > simply a number, so the code point here is 0xE4, or 228 in decimal. > The convention for representing a character, moreover, is U+HHHH; in > this case, you would use U+00E4. I would suggest changing this passage > to something like: > > Here, the second link has a title encoded in UTF-8, uses the German > language ("de"), and contains the Unicode character U+00E4 ("LATIN > SMALL LETTER A WITH DIAERESIS"). Correct. That text was suggested by me; Mark, please take out the \u notation. > ... BR, Julian
Received on Friday, 17 April 2009 10:35:14 UTC