W3C home > Mailing lists > Public > uri@w3.org > October 2012

Re: [whatwg] New URL Standard from Anne van Kesteren on 2012-09-24 (public-whatwg-archive@w3.org from September 2012)

From: Anne van Kesteren <annevk@annevk.nl>
Date: Tue, 23 Oct 2012 10:36:14 +0200
Message-ID: <CADnb78jDTXXm0O+zeAqP4v0gwBdLp2u2oS7aM+hJb6_bqFqX5g@mail.gmail.com>
To: uri@w3.org
I'm not subscribed to this list, but I guess there's a few points I can make.

* This is not about the address bar. The address bar is UI.
Standardizing UI does not pass the test of time.

* If you think the URL Standard fragments, you have cause and effect reversed.

* Building on top of STD 66 is not practical. You want a single
algorithm that deals with parsing, resolving, and canonicalizing.

* That the URL standard will call the input a URL matches common
usage. Given that a relative URL can be empty string, a URL can indeed
be the empty string. Roy thinks this is absurd, I think it's quite
logical. The object model I will probably call "parsed URL", but I'm
open to suggestions.

* For Julian, an example of a URL that would be invalid per STD 66 yet
is transmitted over the wire just fine: http://www.w3.org/% or
http://www.w3.org/?% Also fragments such as #™ do not undergo any
transformation. Fragments are pretty much parsed as literals except
for thirty or so code points.

* And that complex technology creates large standards, I'm not even
sure what to say to that Noah. Yes, the world is uglier than we
thought, but at least now it's written down and should hopefully serve
as a lesson for new things we invent. If there is one thing the WHATWG
has been doing in this space is to reduce the actual complexity by
actively converging implementations. (Actual complexity is increased
by poor standards that not even come close to defining the technology
they are about, such as HTML4.)

* As for contributing to the IETF. I have tried many times (Atom,
HTTP, ietf-charsets, httpstate, IRI, websec, HyBi). There's a lot of
Stop Energy so rather than solving problems I end up explaining the
problem many times over. There's not much interest in doing the hard
work such as writing tests, figuring out how implementations have
actually implemented the standard. Whenever I bring up a couple of
issues in one specification or another I have to be exhaustive rather
than someone taking it as a sign of a larger problem with their body
of work. And if I manage to get the standard changed it's almost often
some watered down wording that does not guide implementors in any way
(e.g. redirects, Content-Location, invalid relative URLs in HTTP).
You'd have to write another standard that actually takes a stance on
the issue. This is why I now rather focus on just doing the work. I
can talk and email all I want, but attempting to prove I'm right by
example seems a more worthwhile use of my time.

Received on Tuesday, 23 October 2012 08:36:42 UTC

This archive was generated by hypermail 2.4.0 : Sunday, 10 October 2021 22:17:56 UTC