RE: Advice on making IRI document suitable for reference by HTML (and other specs)

> This is still confusing IRIs with the arbitrary contents of an
> href (or other) attribute.

To try to bring two things into alignment isn't "confusing"
them. Why shouldn't the most widely deployed implementations
be used as a guideline? 

> The fact is that HTML5 (and others) needs a definition of reference
> and the rules for converting a reference to an IRI or URI.

Yes. I'm willing to admit that it may be necessary to retain some
elements as "preprocessing", although I'm not convinced.

> Trying to pretend that a reference is always an IRI is doomed
> to fail -- you might as well obsolete the RFC and say that
> an IRI is anyString.

I'm not trying to _pretend_ anything, I'm trying to make
it so. And issuing a new version of an RFC *does* make
the old version "obsolete". If the standard doesn't match
what implementations do, obsoleting the standard and
making a new version isn't bad.

I'm not convinced that it is inappropriate to define
a syntax which parses into components, and yet any
string *has* a parse, and that validity is determined
after the parse rather than before. (Especially since
the restrictions on character ranges may be different
from one parsed field to another.)

> Thus making all current references to the standard wrong
> and useless.

If current references to the IRI Proposed Standard don't
match what implementations actually do, then perhaps they
ARE _wrong_, and fixing the specifications to match the
widely deployed and interoperable implementations is 
actually the right thing to do.

> Julian is right.

I didn't read a specific position in Julian's post, but
rather just pointing out there were some existing
specifications that would have to be reworded if
the "no internal spaces" restriction might be required
for those applications.

> What you should be doing
> is defining an algorithm from anyString to the current
> definition of IRI, 

That's what 
http://tools.ietf.org/html/draft-duerst-iri-bis-07#section-7.2 
section 7.2 " Web Address processing" already attempts.
Do you think it accomplishes that? 

> and then change HTML5 so that it uses
> anyString (or whatever you want to call it) as the attribute
> definition. 

That's what was intended by:
http://lists.w3.org/Archives/Public/public-html/2009Nov/att-0670/iri-rewrite-draft.html
Do you think this is the right direction, then?

Some of those definitions are useful outside of the context
of HTML; do you agree with moving some of them into the
IRI-BIS document?

>  My suggested name is "Web reference". 

I used "Web address" rather than "Web reference", since
that's was the term used before.

> Just be
> aware that some HTML5 attributes require a list of
> space-separated references, whereas others require a
> single reference that expects space to be auto-encoded
> by the parser.

I looked through the HTML5 specification for any specific reference
to WEBADDRESS or HTML5 section 2.5, and saw no such attributes;
could you give an example of an HTML5 attribute which requires a
list of space-separated references?

Thanks!

Larry
--
http://larry.masinter.net

Received on Monday, 28 December 2009 22:56:36 UTC