Re: ERB call on addressing
email@example.com (David Durand) wrote:
> I'm not arguing that they get trashed, just that the common practice that
> tells me where to look for parameters (and commonly available code to do it
> for me) is lacking almost everywhere.
Maybe it's becaue most of the CGI stuff I have done has been with Unix
shell scripts or perl, but I really didn't find the one (count it, one)
extra line I had to add to be as much of a pain as you are making out.
Various people have already recommended using ; instead of & as a separator
in one's HTML, and I would expect off-the-shelf CGI packages to handle
that soon where they don't already. This means that there is no
actual difference any more in practice between using & and using ; except
that using & has problems in an SGML/HTML/XML attribute, because it
has to be escaped in a CDATA attribute even though it wouldn't have to
be escaped in CDATA element content. (Presumably "CDATA" should have been
"RCDATA", but it's a little late to fix what that particular mistake now!)
In any case, it's silly for XML to try and standardise on a way to specify
a server side fragment, as the parameters that have to be sent depend on
the content and on the environment. This is over-specification gone wild.
are the same thing written with two syntaxes -- in both cases, perhaps
a program "font-catalogue" is run to create a "virtual document".
(this is a real example, by the way).
You can go to the next page within the font family -- e.g. from bold
to italic -- or to the next family by that vendor (Berthold), or
to the next version of Bembo (e.g. Monotype's) or to the next font
(e.g. Biffo) either staying within Berthold or the next font in the
alphabetical list of all fonts (e.g. Betton), or you can go to the
start of the next foundy (e.g. Bitstream). There are also links to
browse by date or by font type (e.g. Old Style, Geometric Sans) instead
of by font name.
Which "next fragment" do you want to choose?
In HTML, I can do
<link rel="next" ...
and give the link to the next something-or-other, but I can only give one.
I think this lack of generality was always one stumbling block with
the rel-rev work. It was for me, anyway. Sometimes it's worth doing
something that's inadequate, because it covers 70% or 80% of cases.
So we put out rel-rev as an ID, and NCSA and Lynx at least implemented
NEXT as a toolbar icon (well, Lynx shows it in ASCII...).
But the ID said the list was extensible.
Don't impose a syntax before all the requirements are known, if you are
going to be bound by that syntax for a long time.