- From: Maciej Stachowiak <mjs@apple.com>
- Date: Fri, 21 Aug 2009 01:03:17 -0700
- To: Ian Hickson <ian@hixie.ch>
- Cc: Larry Masinter <masinter@adobe.com>, "public-iri@w3.org" <public-iri@w3.org>, public-html@w3.org
Hi Larry, Any update on this? It's blocking resolution of HTML WG ISSUE-56[1]. The requested resolution for ISSUE-56 is to reference IRIbis, but doing so would leave dangling references until the following issues are addressed. Regards, Maciej [1] http://www.w3.org/html/wg/tracker/issues/56 On Jul 28, 2009, at 2:25 PM, Ian Hickson wrote: > On Mon, 13 Jul 2009, Larry Masinter wrote: >> >> This version attempts to integrate the "web address" concept (called >> Hypertext Reference or HREF) into the main IRI specification. The >> text >> has gone through sufficient transformations that I don't have >> confidence >> in its accuracy, but at least it indicates to me that the many >> specs are >> mergable. > > http://tools.ietf.org/html/draft-duerst-iri-bis > > It appears that in the process of merging this: > > http://www.w3.org/html/wg/href/draft-ietf.html > > ...into the above ID, the following key parts were lost: > > * The definition of what is a "valid URL", defined such that an IRI is > only a "valid URL" if its query part will be interpreted according > to > the IRI spec according to the URL parsing algorithm. > > * The definition of what is an "absolute URL", defined such that even > invalid strings can be valid URLs. For example, the following: > > http://example.com/% > > ...is not a "valid URL" but needs to be an "absolute URL". > > * The definition of how to determine whether the following > components are > present in, and how to obtain their value from, a string that may > not > be a "valid URL": > > <scheme> > <host> > <port> > <hostport> > <path> > <query> > <fragment> > <host-specific> > > * The definitions for how to resolve a string to an "absolute URL" > when > the original string is not necessarily a "valid URL". > > (I use the term "URL" here in the HTML5 sense, which has varyingly > been > called a Web Address or an HRef in related work.) > > > The following issues also exist in the draft: > > * "is the script's character. encoding" has a typo (misplaced ".") > > * Step 8 in the algorithm for parsing HRefs appears to be a corrupted > form of the definition of <hostport> from the old HTML5 text. The > new > text as phrased appears to be meaningless. > > * It appears that the parsing algorithm is destructive, in that the > results will not be isomorphic with the input. For example, the > following: > > http://example.com/## > > ...will turn into: > > http://example.com/#%23 > > ...which, once the "resolving" algorithm is reintroduced, will be > incompatible with implemented practice. > > -- > Ian Hickson U+1047E ) > \._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _ > \ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'-- > (,_..'`-.;.' >
Received on Friday, 21 August 2009 08:04:13 UTC