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

It sounds like, with some changes to IRIbis, we have the potential for  
an amicable resolution. I believe the changes to the HTML5 draft  
proposed here would satisfy the intent of Larry's original Change  
Proposal.

My understanding is that, to satisfy the request here, the IRIbis  
draft only needs to define referenceable algrithms with a suitable  
interface - they do not yet need to be correct in all details of their  
internal operations.

Larry, can you comment on the feasibility of the requested IRIbis  
changes? It would be really great to get this HTML WG issue settled,  
so that remaining IRI/URI/URL work can move into the IRIbis WG.

Regards,
Maciej

On Apr 5, 2010, at 4:57 PM, 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.
>
> -- 
> Ian Hickson               U+1047E                ) 
> \._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _ 
> \  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'-- 
> (,_..'`-.;.'
>

Received on Tuesday, 6 April 2010 22:28:21 UTC