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

Clarifying the URL Standard goals

From: Anne van Kesteren <annevk@annevk.nl>
Date: Wed, 7 Nov 2012 22:51:46 +0100
Message-ID: <CADnb78gy7L3psKCsNX8+Ep9BLrMW4Vk5HM3vDRziApjNa1FWAQ@mail.gmail.com>
To: uri@w3.org, public-iri@w3.org
I listened to the audio recording of the meeting and I feel my emails
have been largely misunderstood. I thought I would try again.

As far as the interests of the IETF seem to go, this is what
http://url.spec.whatwg.org/ attempts to do:

* Define the string syntax for URLs (IRI-references, if you wish).

* Define parsing the string syntax into a model (IRI-references ->
URI, if you wish).

* Define serializing the model back into a string syntax.

The string syntax seems non-controversial.

The parsing seems controversial, but the plan is to add an option
there to only parse conforming string syntax and bail on the first
error. (Going past the first error is useful for e.g. browsers /
search engines / wget so they can interoperate with content, but also
for URL validators that want to highlight more than one error in the

The model is currently only documented as a function of the parsing
algorithm. My plan was to align implementations on parsing first
before documenting what model that implied. I already indicated how
this model is incompatible with URI. E.g. a query with a lone "%" can
be the output of the parser, but is definitely not an URI. (This is
why "fixup" is the wrong way to look at this algorithm I think.)

Serializing seems non-controversial.

(I am not sure if it is worth mentioning, but I am doing this work
largely by myself and thus far unpaid. Although browser vendors have
indicated they appreciate what I am doing, I am not representing any
of them, and I definitely care about software other than browsers. My
experience is that what browsers do leaks throughout the ecosystem and
I rather have it documented and confined what is leaked than everyone
having to reverse engineer each other in a race to the bottom.)

Received on Wednesday, 7 November 2012 21:52:24 UTC

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