Re: Urgent: How to fix up references to XMLRIs

On Saturday, August 23, 2008, 7:14:22 PM, Cameron wrote:

CM> Hello Chris.

CM> In a previous telcon, you said that the changes to XLink 1.1 didn’t
CM> necessitate any changes on our part for 1.2T.  However, I notice that
CM> XMLRIs are now not defined in XLink 1.1, and instead defer to LEIRIs,
CM> which are themselves defined in a draft RFC.  How should we fix up the
CM> references?

We can say IRI now, instead of XMLRI.

CM> Should we be changing all XMLRIs to LEIRIs

No. LEIRIs grandfather in a legacy syntax (the "L" in LEIRI) and SVG
has never allowed that legacy, so does not need to grandfather it. We
use IRIs, and we don't allow the extra legacy stuff that XLink,
technically, used to allow but no longer allows, which is
IRI-like-but-not-quite-IRIs (LEIRI).

This was discussed back in March, see several messages in March 2008
on the old WG list which I forwarded from Paul Grosso and John Cowan.
The subject lines were

Fwd: Re: Transition Request: (2nd) PER Request for XML Base Second Edition

Salient points: I asked
> Should specifications that currently use IRI in XML specify 
> LEIRI instead?

Paul replied:
PG> It depends. "LEIRI" is just a new term, not a new concept. If the
PG> concept under consideration is, in fact, a LEIRI, they are welcome
PG> to use it; otherwise, they should not.

Which is clear enough, and we are not using it. Similarly John Cowan
replied:

JC> No. The "L" in "LEIRI" stands for "Legacy"; the LEIRI definition
JC> simply collects under one roof the existing anything-goes
JC> definitions of URI-like objects in older specs (XML 1.0 system
JC> identifiers, XLinks, XML Schema anyURIs, etc.)

Paul also said:

PG> Remember, LEIRI is just terminology. We aren't changing the set of
PG> strings that are allowed by these specs or how those strings
PG> should be processed (though hopefully we are clarifying some
PG> fuzzier bits). So whether you want to change SVG to use the LEIRI
PG> terminology or not, there's nothing wrong with the SVG spec as
PG> written now.

however, the most clear exchange was this one between John Cowan and
myself. I said:

Chris Lilley scripsit:

CL> Thanks, Richard. It does indeed currently refer to them simly as IRIs,
CL> and points to RFC 3987 for the definition. It does also normatively
CL> refer to XLink; but it also says what the type of the attributes are
CL> rather than "they are whatever Xlink says" because, for one thing,
CL> we have a DOM while XLink does not specify one.

JC> Okay, fair enough. So SVG allows a subset of what XLink allows:
JC> nothing amiss with that.

CL> It sounds as if you are saying that SVG should specify a subset of
CL> what XLink and XML Base allow. So we say they accept an IRI.

CL> Which is simple, but then we catch flack for embrace-and-extend (well
CL> ok embrace-and-subset).

JC> I think there is a huge difference between extending and subsetting.
JC> You are already subsetting XLink by using simple links only (indeed,
JC> the Core WG is considering making simple-links-only a formal conformance
JC> level of XLink 1.1).  So disallowing LEIRIs that are not IRIs, which
JC> you are already doing implicitly, is perfectly fine.

That last point is the crucial one. So we don't need to use XMLRI
anymore. we can just use IRI instead. Its currently defined by RFC
3977, and will at some time later be updated to be defined by
son-of-3987. Our references section would (continue to) point to RFC
3987 for SVG Tiny 1.2

See also ACTION-1373

In summary we do not need to use, reference, or wait for LEIRI, and we
already have archived email from the relevant groups telling us that
what we are doing is fine. So I don't expect there to be an issue here
from those groups.

-- 
 Chris Lilley                    mailto:chris@w3.org
 Technical Director, Interaction Domain
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG

Received on Monday, 25 August 2008 16:26:57 UTC