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

Some notes on the ontology of resources, fragments, and
XML documents; those who like this kind of thing will find
it just the kind of thing they like.

> On May 3, 2017, at 11:21 AM, C. M. Sperberg-McQueen =
<[email protected]> wrote:
>=20
> ...
>=20
> Consider a document with a default namespace of
> http://www.tei-c.org/ns/1.0, retrieved from http://example.com/foo
> containing both
>=20
>    <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>
>=20
> and (with no xml:base attributes on any ancestors)
>=20
>  <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>Par=
a 5</p>
>  </div>
>=20
> 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
>=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
>=20
> If I am reading RFC 3986 correctly, ...
>=20
> I think that this entails the view that all of the items marked with
> asterisk denote the 'rendition' element shown.  ...
>=20
> I think it also entails the view that from the uses of xml:base shown
> we can infer that the URIs
>=20
>    http://example.com/foo
>    http://example.org/blort
>=20
> 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.

On further reflection (believe me, dear Reader, I am as tired of
this subject as you are; I=E2=80=99d like to stop thinking about it just =
as much
as you might like to stop reading about it), I don=E2=80=99t think this =
entailment
holds. =20

The spec seems to be committed to the view that

    P1 The two URIs

      http://example.com/foo#bar
      http://exampe.org/blort#bar

    identify the same fragment. =20

If we had as a principle that=20

    P2 No fragment can be part of more than one document.

then P1 and P2 together would require the entailment mentioned above,=20
namely that

    P3 The two URI references

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

    identify the same document.

But I don=E2=80=99t know of anything in any relevant specification that =
would
secure proposition P2.  If we accept proposition

    P4 For XML documents every fragment is an XDM node.

then I think P2 would follow, but nothing requires that we identify =
fragments
with XDM nodes.  (And if we simply identify fragments with XML=20
*elements*, then I think it=E2=80=99s clear that P2 is not justfied by =
the XML
spec.  This is not a universally held view, but none of those who have
disagreed with me have been willing to explain how their view of
elements is grounded in the spec.  So I cannot provide any account=20
of their reasoning.)



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