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

> On May 4, 2017, at 12:28 PM, Hugh Cayless <[email protected]> =
wrote:
>=20
> That's a rather favorable interpretation on your part. One person =
agrees with you without elucidating,

I=E2=80=99m not sure this is true.  What Eliot Kimber said is that in =
the context given, =E2=80=98#apple=E2=80=99 identifies the same thing as =
=E2=80=98http://www.dictionary.com/a.html#apple'.  Does that distinguish =
between the two (? are there just two?) =E2=80=94 does that distinguish =
among the various interpretations of the situation offered so far?

I don=E2=80=99t think so.  I think the disagreement we have is not over =
the statement  affirmed by Eliot Kimber, but over the following two =
claims:

  C1 In the context described, =E2=80=98#apple=E2=80=99 is a =
same-document reference and
  can therefore by definition be dereferenced without a new retrieval =
action.

  C2 In the context described, =E2=80=98#apple=E2=80=99 does not refer =
to the element in the
  current document with xml:id=3D=E2=80=9Capple=E2=80=9D (if any); it  =
cannot be dereferenced=20
  without a new retrieval action.

I intend C1 as a representation of the interpretation of 3986 I=E2=80=99ve=
 been offering, and C2 as a representation of the interpretation offered =
by John McCaskey. (SRCBS and XVAI, in my note of earlier today.

> one says this discussion has jumped the shark (which is fair), and the =
third (Michael Kay) gives a fuller answer which adds up to "it depends". =
Michael Kay is quite correct that in the context where a document =
retrieval is *expected* to occur, the URI would indeed be computed with =
reference to its base and fetched.=20

The URI is *always* computed with reference to its base. =20

Optimizations which produce the same result are, of course, allowed.  =
The preceding paragraph is a claim about the meaning of certain language =
constructs, not a claim about what the CPU and network controller do =
during evaluation of an expression by a conforming processor.

If it is then determined to be a same-document URI, the resource =
identified by that URI is then =E2=80=9Cdefined to be within=E2=80=9D =
the current document; in consequence no new retrieval is necessary and a =
new retrieval should be avoided.  The 'should' here means that 3986 =
recommends that new retrievals be avoided, but does not forbid new =
retrievals; if conforming processors or specs have good reason for =
launching new retrievals, that's not a violation of the rules of 3986.  =
The XSLT spec defines the document() function as always launching a new =
retrieval.  (Note that this does not amount to any claim by the XSLT =
spec that the relevant resource is not within the current document.)

>=20
> The thing is, I'm not aware of any TEI attributes or element/attribute =
combinations which are defined as *forcing* a retrieval action. I'd be =
happy to be corrected if I'm missing any, of course.=20
>=20
> It's fair to ask not just how one might expect them to behave, but =
what same-document references *mean* in the context of TEI documents =
with @xml:base. I agree this is something we ought to make clear. I =
think there is some possibility of wiggle room, given that TEI has its =
own media type. But I also think that we'd be better off adhering to the =
letter of RFC 3986. The use of same-document references in TEI documents =
is ubiquitous, and I'm firmly against anything that might break them.

Is it clear what counts as breakage, here?

If a given interpretation of the URI specs causes some URI references to =
break (by which I mean: to have an interpretation different from what =
the encoders intended), can we be confident that a contrary =
interpretation will not break any?  Or is it the case that one =
interpretation will break some URI references, and a different =
interpretation will break others?=20

When there are two possible interpreations of a given rule in a spec, =
it=E2=80=99s seldom the case that everyone interprets it the same way.  =
There is some risk that your choice does not lie between breaking things =
in TEI documents and not breaking them, but between breaking those =
belonging to one project and breaking those belonging to another =
project.

> For what it's worth, modern web browsers seem to agree with your =
interpretation (mutatis mutandis=E2=80=94HTML base is not @xml:base). As =
far as I can tell, probably because of a desire on the part of the =
Mozilla developers back in the day to maintain compatibility with IE =
4(!).[1]

Can you expound? =20

Do you mean that in an HTML 4.01 or XHTML 1.0 document at =
http://example.com/doc.html containing <base =
href=3D=E2=80=9Chttp://example.org/base.html=E2=80=9D>, a link of the =
form <a href=3D=E2=80=9C#quovadis=E2=80=9D>where does this connect =
to?</a> will go to =E2=80=A6 where? =20

I think the two obvious things one might expect to see in the address =
bar after traversing that link are

    http://example.com/doc.html#quovadis
    http://example.org/base.html#quovaids

In the first case, this will happen either after a document refresh or =
without a refresh (just scrolling to the place).

If a browser shows one of these addresses, does that constitute a claim =
that the other identifies a different resource?  Or does it only =
constitute a decision on the part of the browser about which of the two =
possible paths to a given resource it should take?


> To further complicate matters, the author of RFC 3986, Roy Fielding, =
has said that using @xml:base in the way you propose, i.e. to enable =
shorthand references rather than to set a canonical URI for the current =
document, is abusive.[2]

Thank you for that reference.=20

I think the rules in 3986 make perfect sense if one assumes Roy =
Fielding=E2=80=99s principle that the base URI within a document should =
be the base URI of the document, and that using xml:base or html:base to =
shorten references which would otherwise be long is not a scenario worth =
bending over backwards for.  (That is, it seems to me to simplify =
matters, rather than complicating them.)

If one doesn=E2=80=99t want to make that assumption, some relatively =
simple rules like the following might go some distance towards reducing =
the likelihood of unpleasant surprises:

  - Use the form =E2=80=9C#fragment=E2=80=9D only for references to =
locations in the current document.  These will always be same-document =
references within the meaning of RFC 3986.
  - Use xml:base to set all but the last bit of the URI, but not to set =
a full document URI:  =
xml:base=3D=E2=80=9Chttp://dictionary.example.org/entries/=E2=80=9C with =
relative references to =E2=80=9Ca.html#apple=E2=80=9D and =
=E2=80=9Ca.html#anodyne=E2=80=9D will be better than =
xml:base=3D=E2=80=9Chttp://dictionary.example.org/entries/a.html=E2=80=9D =
with relative referencs to =E2=80=9C#apple=E2=80=9D and =E2=80=9C#anodyne=E2=
=80=9D.  These will never be taken to be same-document references.

Note, however, that while =E2=80=9C#fragment=E2=80=9D will always be a =
same-document reference, it will ALSO always be a reference to the given =
fragment in the resource identified by the base URI.  If that=E2=80=99s =
not logically the same as the resource within which the reference =
occurs, you=E2=80=99re playing with fire:  RFC 3986 says =E2=80=9C#fragmen=
t=E2=80=9D =E2=80=9Cshould=E2=80=9D be dereferenced without a new =
retrieval, not that it must be.  Any software will be perfectly within =
its rights to retrieve the base URI and look for the fragment there.
=20
>=20
> References:
> 1. =
http://w3future.com/weblog/2005/01/13.xml#stillBugsInTheImplementationOfHt=
mlHyperlinks
> 2. http://w3future.com/weblog/2005/08/14.xml#howToUseBaseUris=20


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