W3C home > Mailing lists > Public > public-html@w3.org > April 2010

Re: Change definition of URL to normatively reference IRI specification using a well-defined interface

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 6 Apr 2010 00:13:39 +0000 (UTC)
To: public-html@w3.org
Message-ID: <Pine.LNX.4.64.1004060012040.4065@ps20323.dreamhostps.com>
On Mon, 5 Apr 2010, Ian Hickson wrote:
> 
> ISSUE-56
> ========
> 
> SUMMARY
> The HTML specification is changed slightly to reference the IRI 
> specification using a well-defined interface.
> 
> RATIONALE
> To ensure a clean modular separation of the IRI and HTML specifications, 
> an interface is needed. This allows the specifications to co-exist in a 
> well-defined way without each specification needing to be continually 
> updated as the other is fixed (for example, changing references to section 
> numbers or step numbers).
> 
> DETAILS
> Update the IRI specification to define two algorithms:
> 
>  * parsing an address (relative or absolute): algorithm to obtain a 
>    failure/success condition (not the same as whether the input is 
>    valid or not, just whether it can be parsed), and the following 
>    components, from parsing an arbitrary string:
>     - <scheme> component
>     - <host> component
>     - <port> component
>     - <hostport> component
>     - <path> component
>     - <query> component
>     - <fragment> component
>     - <host-specific> component
> 
>  * resolving an address A relative to a base address B with an encoding C: 
>    algorithm for parsing an arbitrary string A and resolving it relative 
>    to address B (which will have been resolved, but may be invalid), using 
>    a specified character encoding C, and returning either success or 
>    failure, and in the case of success, a string, with the following 
>    conditions:
>     - the output of the algorithm must be idempotent even if the base 
>       argument is changed (i.e. once resolved, resolving it again with 
>       the same character encoding cannot change the result)
>     - resolving preserves errors, e.g. resolving "http://example.com##"
>       returns "http://example.com/##" not "http://example.com/#%C3".
> 
> Update the HTML spec to use these algorithms and reference the IRI spec 
> that defines them.
> 
> 
> IMPACT
> 
> POSITIVE EFFECTS
> None.
> 
> NEGATIVE EFFECTS
> None.
> 
> CONFORMANCE CLASS CHANGES
> None.
> 
> RISKS
> None.

On the assumption that either Larry's change proposal or my change 
proposal above will get accepted, I changed the spec a bit to make the 
resulting change easier to make:

   http://html5.org/tools/web-apps-tracker?from=4973&to=4974

(I've marked in red (class=XXX) the bits that are most likely to be the 
bits that need changing based on what the chairs decide here.)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 6 April 2010 00:14:08 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:16 UTC