On 10/12/2008, at 10:11 PM, Anne van Kesteren wrote:
If you have
http://example.com/foo
http://example.com/FOO
they would be the same in HTML, but would not be for the Link HTTP
header...
Correct.
Ignoring case when comparing the short-form, registered values makes
sense, and should be covered by
HTML defines link relation values as case-insensitive, while the
Link
header's syntax does not. Therefore, it is important to case-
normalise relation values in HTML before comparing or converting
them
to Link headers.
although that could use some tweaking.
However, ignoring case when comparing entire URIs (i.e., non-registry
values) seems like a pathological case. I would posit that people are
much more aware of case issues in full URIs, because they have to be
on the Web today anyway, no matter how many corrections their browser
makes for them.
(It's also not really clear to me why relationship values are have
to be resolved and why we not just use the same rules as we do for
namespaces.)
They don't; I think the clarification that Roy requested earlier will
help here.
Also, I definitely do not want to start having to implement support
for http://www.iana.org/assignments/relation/stylesheet besides just
stylesheet. (Not for the Link HTTP header or for the HTML elements.)
That's just additional complexity for no gain and will only lead to
bugs and differences among browsers.
Not if it's specified sensibly, clearly and unambiguously. The worst
possible thing to put in here would be advice -- but not a requirement
-- to use the short form when available.
The other approach is to require the short form to be used when
registered. However, that seems more of a special case that's likely
to cause problems; software producing links that wishes to mix
registered and non-registered relations will have to remember and test
for the difference, and serialise accordingly. That has the potential
for bugs and resulting differences among implementations (not just
browsers).
The other, other approach is to dispense with the notion that a
registered value is a URI, while still allowing URIs (and only
absolute URIs, ever) for non-registered URIs. This would necessitate
that the registered values MUST conform to sgml-name or similar, to
allow them to be distinguished from URIs, and would preclude some
future application from using relative URIs as relations (e.g., if you
had an XML format and used a lot of locally-defined relations, you
couldn't use XML base to shorten them, because they'd be potentialy
ambiguous), but otherwise this might be workable.
This latter approach would also make defining case insensitivity for
registered values easier.
Thoughts (everyone, not just Anne)?
In HTML5 there is no rev "link-param" because (non-academic)
studies have shown that people do not really know how to use it.
See current discussion about deprecating it.
What does deprecating mean here for the various parties (e.g.
implementors and authors)?
It depends on where the discussion goes, but right now it looks like
it means that authors are cautioned not to use it, as it's confusing,
and implementers may or may not support it at their peril/pleasure.
The only requirement is that they not blow up when they see a rev (but
that goes for any unrecognised extension).
In HTML5 media, hreflang, and sizes (just for <link>) also
influence the relationship. Your draft does not have these "link-
param"s.
Other extensions are allowed; again, see the appendix about use in
HTML.
It says they are believed to be defunct... media is pretty damn
important for style sheets at least.
I'll remove the "defunct" language in the next draft.
I'm hesitant to define media in this draft without a format-neutral
description of its semantics and possible values, but again it is
accommodated already.
--
Mark Nottingham http://www.mnot.net/
