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

> On May 3, 2017, at 9:51 AM, Conal Tuohy <[email protected]> wrote:
>=20
>=20
> On 4 May 2017 at 01:22, Hugh Cayless <[email protected]> wrote:
> A URI reference which is empty or begins with "#" is a same-document =
reference only if the xml:base in scope at that point in the document is =
the URI of the document itself.=20
>=20
> No. It's a same-document reference even if the base URI is different =
from the document URI, because the algorithm for resolving it will =
compare it to the base URI, not the document URI. I will freely admit =
this is a bit weird, but it is definitively weird.=20
>=20
> On re-reading it I do think you're right; it does seems weird but I =
think it is defined that way in rfc3986. I take back everything I said =
about same-document references! You learn something new every day.
>=20
> So if a "fragment identifier" URI reference is always by definition a =
"same-document" reference, then resolution of such URI references should =
not (per rfc3986) trigger a retrieval. If you were to set xml:base on a =
root TEI element, then "fragment identifier" URI references would refer =
to elements in the same document.=20
>=20
> This would mean John McCaskey could safely use fragment identifiers to =
point to <rendition> elements, though the xml:base of the <rendition> =
elements would need to be set to the same value as the xml:base of the =
elements which referred to the <rendition> elements.=20

I think I=E2=80=99m with you up to that last bit.  I don=E2=80=99t think =
there is any
requirement that the base URI used to resolve relative references
among =E2=80=98rendition=E2=80=99 elements be the same as the base URI =
used to resolve
relative references that point to those rendition elements.

[Those who don't want to work this through in full-on language-lawyer
mode will do better to stop reading here.  Thank you and have a nice
day.]

Consider a document with a default namespace of
http://www.tei-c.org/ns/1.0, retrieved from http://example.com/foo
containing both

    <rendition
        xml:id=3D=E2=80=9Cbar=E2=80=9D
        xml:base=3D=E2=80=9Chttp://example.com/barracuda=E2=80=9D>
        =E2=80=A6.
    </rendition>

and (with no xml:base attributes on any ancestors)

  <p rendition=3D=E2=80=9C#bar=E2=80=9D>Paragraph 1</p>
  <p rendition=3D=E2=80=9Chttp://example.com/baz#bar=E2=80=9D>Para 2</p>
  <p rendition=3D=E2=80=9Chttp://example.org/blort#bar=E2=80=9D>Para =
3</p>
  <p rendition=3D=E2=80=9Chttp://example.com/foo#bar=E2=80=9D>Para 4</p>
  <p rendition=3D=E2=80=9Chttp://example.com/barracuda#bar=E2=80=9D>Para =
5</p>
  <div xml:base=3D=E2=80=9Chttp://example.org/blort=E2=80=9D>
    <p rendition=3D=E2=80=9C#bar=E2=80=9D >Para 6</p>
    <p rendition=3D=E2=80=9Chttp://example.com/baz#bar=E2=80=9D>Para =
7</p>
    <p rendition=3D=E2=80=9Chttp://example.org/blort#bar=E2=80=9D>Para =
8</p>
    <p rendition=3D=E2=80=9Chttp://example.com/foo#bar=E2=80=9D>Para =
9</p>
    <p rendition=3D=E2=80=9Chttp://example.com/barracuda#bar=E2=80=9D>Para=
 5</p>
  </div>

As I read the specs, the absolute URIs used to dereference the URIs in
the rendition attributes are (numbers indicate the p elements in
question).  Asterisks mark same-document references, as that
term is defined in the RFC.=20

   1* http://example.com/foo#bar=20
   2  http://example.com/baz#bar=20
   3  http://example.org/blort#bar=20
   4* http://example.com/foo#bar=20
   5  http://example.org/barracuda#bar
  =20
   6* http://example.org/blort#bar=20
   7  http://example.com/baz#bar=20
   8* http://example.org/blort#bar=20
   9  http://example.com/foo#bar
 10 http://example.org/barracuda#bar=20

If I am reading RFC 3986 correctly, the items marked with asterisk
"should not" lead to a new retrieval action if dereferenced; that is
only a SHOULD not a MUST, so there is no guarantee.

I think that this entails the view that all of the items marked with
asterisk denote the 'rendition' element shown.  At least, if we take
that view, it makes sense that dereferencing these items will not need
any new retrieval action.

I think it also entails the view that from the uses of xml:base shown
we can infer that the URIs

    http://example.com/foo
    http://example.org/blort

both denote the current document at the moment it was retrieved (or,
more precisely perhaps, that the current document was, at the moment
of its retrieval, a representation of the resource(s) denoted by these
two URIs.

=46rom these propositions a sufficiently aggressive optimizer might
conclude that ALL of the references 1, 3, 4, 6, 8, 9 denote the same
'rendition' element, and therefore that NONE of them require a new
retrieval action.  A less aggressive optimizer might not reach this
conclusion and might start a new retrieval action for 3 and 8.  If the
result of that retrieval action is not what the encoder intended, then
perhaps the encoder did not attend closely enough to the semantic
implications of xml:base. =20

Depending on how we think about the relation between resource and
representation, it may or may not be legitimate to infer that the two
URIs given above all denote the same resource.  On the whole, I think
that that inference is not legitimate: since representations can lose
information, it's quite possible that the same object can be a
representation of two different originals: a second-generation copy,
for example, can be used both as a representation of its
first-generation exemplar and as a representation of the original.  In
some cases important scholarly issues hang on the the details of such
a situation and on whether a given aspect of the second-generation
copy faithfully represents the both the original and the
first-generation copy or only the latter.  Keyword: Jane Austen Rice
portrait.

I don't know of anything that licenses the inference that URI
references 2, 5, 7, or 10 are references to the current document; I
would expect software attempting to dereference these to start a new
retrieval action.
  =20
If I am reading your (Conal Tuohy's) logic correctly, you are assuming
that the presence of an xml:base attribute on the rendition element
licenses the inference that the URI of the 'rendition' element is

    http://example.com/barracuda#bar=20

and then the further inference that only the URI references 5 and 10
actually denote the rendition element in question.  But I see no
grounds for these inferences.

A human or program making the inference that xml:base provides a URI
that can be used to refer to the current resource may infer from the
xml:base attribute on 'rendition' that the URI

    http://example.com/barracuda

is yet another URI whose resources is (or can be) represented by the
current document.  Such a processor might be tempted to resolve URI
references 5 and 10 without a new retrieval action; I have no idea
whether spec lawyers would support that inference or not, nor do I
know whether any software behaves this way.  (A casual examination of
some of the specs suggests that the last effort to say what the HTML
'base' element means, semantically, was a long and arduous discussion
in the context of HTML 3.0.  (The HTML 'base' element is relevant
here, I think, because I think the natural reading of the xml:base
spec is that xml:base is intended to have the same semantics as HTML
'base', modulo the fact that an HTML document is only allowed on
'base' element.)  As far as a quick glance reveals, HTML 2.0, 3.2, and
4.01 all just say the 'base' element is used in URI resolution, with
no discussion of whether there is any relation between the resource
identified by the URI and the representation one is reading.  (As far
as I know, HTML 5 has no 'base' element.)

Perhaps the discussion of same-document references in 3986 is a relic
of earlier times; perhaps it is a throwback; perhaps it is the revenge
of the editors of the RFC on those who refused to listen to them in
the discussions of HTML 'base' element.

In sum: as Hugh Cayless and others have observed (or argued), any
relative reference given in the document as '#' plus fragment
identifier will invariably refer to the indicated element of the
current document.  As has been observed by Conal Tuohy (and others?
I'm losing track, sorry), so will absolute references whose scheme,
host, and path information match the current base URI.

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