> Joe English wrote:
> > Applications can be updated to treat "cheese" just like "x-cheese"
> > once "cheese" becomes standardized fairly easily, but what if
> > you have a huge collection of documents that use "x-cheese"?
>
> If it worked the other way, and you had lots of documents with "cheese"
> in them, and you the meaning of "cheese" ended up being Mocrosoft's and
> not Netscape's (or the other way round), you'd have documents with something
> incorrect in them and no way of knowing it.
That's why (in my proposal) browsers would not be allowed
to treat link relations specially without seeing the support
declaration.
> > I see this as more of a namespace management problem than an
> > standardized/experimental identification problem -- we want to
> > avoid the situation where an author uses a link relation name
> > that later gets standardized to mean something unexpected.
>
> Yes. Hence the X-
The X- doesn't solve this problem. Scenario: Netscape implements
a "cheese" link and, since it's experimental, they use REL=X-CHEESE.
Lots of people use it. Microsoft, not knowing this, invents a new
link relation with different semantics but they also call it CHEESE.
And, since it's experimental...
[ My proposal still has a namespace problem, though, namely in the
<?LINKREL ...> support declaration identifiers. If both Microsoft
and Netscape deployed CHEESE relations and both used the relation set
identifier DAIRYPRODUCTS, there'd still be a problem.
I'd like to suggest a further convention that experimental link relation
set identifiers should begin with an application-specific prefix;
for example, people who want the Netscape semantics would use:
<?LINKREL NETSCAPE-DAIRYPRODUCTS>
and those who want the MS semantics would use:
<?LINKREL MICROSOFT-DAIRYPRODUCTS>
or, if you really want the X-,
<?LINKREL X-MICROSOFT-DAIRYPRODUCTS>.
If and when the link relation set becomes standardized, the
declaration becomes:
<?LINKREL DAIRYPRODUCTS>
or maybe:
<?LINKREL IETF-DAIRYPRODUCTS>
Users will still need to update all their documents, but they
only need to change the declaration (which appears once per document).
None of the <LINK> and <A> element REL attributes will need to be changed.
]
[regarding the use of processing instructions instead of elements]
> I am reluctant to suggest requiring that browsers support new kinds
> of SGML markup. Although, I like the idea of
It isn't explicitly stated in the HTML draft, but I'd say that
browsers are already required to support PIs by virtue of
the first sentence of section 2:
HTML is an application of ISO Standard 8879:1986 - Standard
Generalized Markup Language (SGML).
Most current browsers do in fact support (i.e., ignore) PIs
by treating them as "unrecognized tags".
> I suppose you could do
> <HEAD>
> <LINKSET HREF=".....">
> <LINKSET HREF="......">
> <LINK REL=.... HREF=....>
> <LINK LINKSET=.... REL=..... HREF=.....>
> </HEAD>
>
> but I think this is more complex than necessary.
>
> The idea of sets of link semantics that can be associated
> with a URI _does_ seem sound to me. I'd rather do it without ProcInsts if
> we can.
I would prefer PIs over elements for this purpose: the support
declaration is after all an application-specific instruction,
which is exactly what PIs are for, and the declaration syntax
could be more easily extended without changing the DTD. But
the exact markup isn't crucial, IMO.
(I've noticed that many SGML gurus seem to have an instinctive
mistrust of processing instructions... I wonder why that is?)
--Joe English
joe@trystero.art.com