Re: @xml:base with @rendition (and maybe other pointers)

> On May 3, 2017, at 4:13 PM, John P. McCaskey =
<[email protected]> wrote:
>=20
> The special behavior of same-document references in RFC 3986 is =
disavowed by W3C:=20

Well, that=E2=80=99s a formulation that caught my attention!  My heart =
rate would be
nearer normal if you had said =E2=80=9Cdisavowed by the W3C xml:base =
spec=E2=80=9D. =20

But I don=E2=80=99t think xml:base does disavow what 3986 says about =
same-document
references.

>     4.4 Interpretation of same-document references
>=20
>     RFC 3986 defines certain relative URI references, in particular
>     the empty string and those of the form #fragment, as same-document
>     references. Dereferencing of same-document references is handled
>     specially. However, their use as the value of an xml:base
>     attribute does not involve dereferencing, and XML Base processors
>     should resolve them in the usual way. In particular, xml:base=3D""
>     does not reset the base URI to that of the containing document.
>=20
>     Note:
>=20
>         Some existing processors do treat these xml:base values as
>         resetting the base URI to that of the containing document, so
>         the use of such values is strongly discouraged.
>=20
>=20

> This says:
> RFC 3986 defines special =E2=80=9Cdereferencing=E2=80=9D of empty =
strings and #fragments. But over here in XML-land, we don=E2=80=99t do =
=E2=80=9Cdereferencing.=E2=80=9C That=E2=80=99s not a word we use here. =
Ignore that stuff about same-document references. Just resolve empty =
strings and #fragments as specified in the W3C Recommendation above. And =
those of you who did carry that stuff over from 3986 to XML-land, shame =
on you. You messed things up for the rest of us.=20

No, I don=E2=80=99t think that=E2=80=99s what it means.  It says that =
the correct processing=20
of xml:base attributes does not involve dereferencing any URIs, not that
URIs in XML contexts are never dereferenced.

Dereferencing is not defined by the passage of RFC 3986 that talks=20
about same-document references; it's a standard computing term (one=20
of many introduced by the Algol 68 spec, regarded by some at the time=20
as a terminological nightmare).  In Algol 68, it is one of several =
operations=20
which coerce things from one type (mode, in Algol 68 terms) to another. =20=

As the spec puts it:

    Dereferencing serves to obtain the value referred to by a name,
    as in x :=3D y, hwere y yields a name referring to a real number and
    it is this number which is assigned to the name yielded by x.

In more general programming contexts, =E2=80=98dereferencing=E2=80=99 is =
used to describe=20
following a pointer (coercing from a pointer type to the type of the =
object=20
pointed at); since retrieving a representation of the resource denoted
by a URI seems analogous to following a pointer in C, the term is used
by RFC 3986 to denote operations which require access to (some
representation of) the resource denoted by a URI:

   URI "resolution" is the process of
   determining an access mechanism and the appropriate parameters
   necessary to dereference a URI; this resolution may require several
   iterations.  To use that access mechanism to perform an action on the
   URI's resource is to "dereference" the URI.

There are surprising numbers of otherwise intelligent people who seem=20
to assume that in order to do anything with a URI, one must dereference =
it. =20
So descriptions of using URIs for unique identification (as in namespace =
names)
or for certain kinds of string manipulation (as in xml:base) frequently =
find
it necessary to say explicitly that when testing namespaces for =
identity,
calculating the expanded name of an element or attribute (or other =
object
named by a QName), calculating the current base URI in a document
that uses xml:base, or absolutizing a relative reference against a base
URI, none of the URIs involved need to be dereferenced.

Since resetting the value of the base URI does not involve dereferencing
either the old or the new base URI, the rules for calculating the new =
base
URI (which may involve absolutizing a relative reference against a base =
URI)=20
are not affected by the passage in RFC 3986.  That passage merely =
observes=20
that some absolute URIs can be dereferenced without a fresh retrieval =
action.
It does not prescribe any special rules for the absolutization =
algorithm.

>=20
> A note has:
> 5. The meanings of xml:base=3D"" and xml:base=3D"#frag" have been =
clarified;
> This says:=20
> In this second version of this recommendation, we added paragraph 4.4 =
specifically to get you 3986 people to stop polluting our W3C with your =
special cases. Stop doing that.
> No?

No.  (At least, not in my view.)  I think it means =E2=80=98OK, we found =
some
people assuming that the empty string means something special,
instead of using the standard rules for resolving relative references
against a base URI.  Why can=E2=80=99t people just read the damn specs?
So we have added an explicit note saying that no, neither =E2=80=9C=E2=80=9D=
 nor =E2=80=9C#frag=E2=80=9D=20
is magic.  And then a note observing that some software has not yet=20
gotten the message, so people need to be careful.=E2=80=9D

It is certainly imaginable for rivalries to develop between different=20
organizations developing technical specs in related or overlapping
areas, so your gloss is not unthinkable.  But the editors of RFC 3986
are not without influence within W3C.  I do not believe that any W3C=20
specs incompatible with RFC 3986 exist, for the very simple reason=20
that proposals incompatible with the defining document for URIs do=20
not achieve consensus within W3C working groups.


********************************************
C. M. Sperberg-McQueen
Black Mesa Technologies LLC
[email protected]
http://www.blackmesatech.com
********************************************