Re: @xml:base with @rendition (and maybe other pointers)
"John P. McCaskey" <[email protected]> Thu, 4 May 2017 15:31:42 -0400
| Newsgroups | gmane.text.tei.general |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--------------86A46EBA1F8CCE9B2CA56A17
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
What is the short bottom-line guidance for someone trying to encode a=20
document? Is it this?
To point inside a TEI document, as for @rendition, use pointers of
the form #destination. Any later changes to xml:base values will not
mess up your internal # pointers.
Don=E2=80=99t try to point outside your TEI document by using xml:bas=
e plus
a #destination in the pointer attribute. No xml:base attribute will
be prepended to a pointer that begins with a #.
Even if I and others find that idiosyncratic and surprising, it=E2=80=99s=
=20
unambiguous, has practical benefits, requires no knowledge of RFCs or=20
W3C specs, is easy to articulate, and is easy to encode to.
John
On 5/4/2017 2:28 PM, Hugh Cayless wrote:
> That's a rather favorable interpretation on your part. One person=20
> agrees with you without elucidating, one says this discussion has=20
> jumped the shark (which is fair), and the third (Michael Kay) gives a=20
> fuller answer which adds up to "it depends". Michael Kay is quite=20
> correct that in the context where a document retrieval is *expected*=20
> to occur, the URI would indeed be computed with reference to its base=20
> and fetched.
>
> The thing is, I'm not aware of any TEI attributes or element/attribute=20
> combinations which are defined as *forcing* a retrieval action. I'd be=20
> happy to be corrected if I'm missing any, of course.
>
> It's fair to ask not just how one might expect them to behave, but=20
> what same-document references *mean* in the context of TEI documents=20
> with @xml:base. I agree this is something we ought to make clear. I=20
> think there is some possibility of wiggle room, given that TEI has its=20
> own media type. But I also think that we'd be better off adhering to=20
> the letter of RFC 3986. The use of same-document references in TEI=20
> documents is ubiquitous, and I'm firmly against anything that might=20
> break them.
>
> For what it's worth, modern web browsers seem to agree with your=20
> interpretation (mutatis mutandis=E2=80=94HTML base is not @xml:base). A=
s far=20
> as I can tell, probably because of a desire on the part of the Mozilla=20
> developers back in the day to maintain compatibility with IE 4(!).[1]
>
> To further complicate matters, the author of RFC 3986, Roy Fielding,=20
> has said that using @xml:base in the way you propose, i.e. to enable=20
> shorthand references rather than to set a canonical URI for the=20
> current document, is abusive.[2]
>
> Given all this, I still agree with Michael Sperberg-McQueen's fuller=20
> explication of the issues at hand. I would interpret same-document=20
> references as pointing to the current document, with the caveat that=20
> there might be, now or in the future, certain pointer attributes or=20
> element/attribute combinations that mandate a retrieval action. Such a=20
> retrieval would necessarily use whatever base was defined for the URI=20
> in question.
>
> References:
> 1.=20
> http://w3future.com/weblog/2005/01/13.xml#stillBugsInTheImplementationO=
fHtmlHyperlinks
> 2. http://w3future.com/weblog/2005/08/14.xml#howToUseBaseUris
>
> On Thu, May 4, 2017 at 10:16 AM, John P. McCaskey=20
> <[email protected] <mailto:[email protected]>> wrote:
>
> I asked about this over at XML-DEV,
> http://lists.xml.org/archives/xml-dev/201705/msg00008.html
> <http://lists.xml.org/archives/xml-dev/201705/msg00008.html>.
>
> Opinion there is with me and opposite the majority here.
>
> Readers there don=E2=80=99t seem to think there is anything to deba=
te. I
> got one short answer and one dismissive comment about =E2=80=9Dques=
tions
> that simple.=E2=80=9D Someone take a look and be sure I didn=E2=80=99=
t word my
> question unfairly.
>
> Whichever interpretation TEI adopts, sounds like it should be
> documented in the Guidelines or a note somewhere.
>
> If the McCaskey/XML-DEV interpretation is adopted, the GitHub
> issue I posted about @rendition stands. If not, that issue goes awa=
y.
>
> John
>
>
>
> On 5/3/2017 8:03 PM, Hugh Cayless wrote:
>> Those are the cards we've been dealt, yeah.
>>
>> Sent from my phone.
>>
>> On May 3, 2017, at 19:53, John P. McCaskey
>> <[email protected] <mailto:[email protected]>> wrote=
:
>>
>>> So, bottom line: A standalone fragment identifier refers to the
>>> loaded document and all the xml:base values above it in the
>>> hierarchy are irrelevant. Encoders cannot use xml:base to direct
>>> a standalone #fragment value to a location outside the loaded
>>> document.
>>>
>>> Is that right?
>>>
>>> --
>>>
>>>
>>> On 5/3/2017 6:20 PM, Hugh Cayless wrote:
>>>> No. This clarifies the expected behavior when (e.g.) you have
>>>> @xml:base=3D"#frag". It says nothing whatever about <p
>>>> rendition=3D"#foo">. I don't think these specifications interact
>>>> in the way you're positing. Quite the opposite.
>>>>
>>>> On Wed, May 3, 2017 at 6:13 PM, John P. McCaskey
>>>> <[email protected] <mailto:[email protected]>> wro=
te:
>>>>
>>>> The special behavior of same-document references in RFC
>>>> 3986 is disavowed by W3C:
>>>>
>>>> 4.4 Interpretation of same-document references
>>>>
>>>> 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.
>>>>
>>>> Note:
>>>>
>>>> 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.
>>>>
>>>> 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.
>>>>
>>>>
>>>> A note has:
>>>>
>>>> 5. The meanings of xml:base=3D"" and xml:base=3D"#frag"
>>>> have been clarified;
>>>>
>>>> This says:
>>>>
>>>> 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?
>>>>
>>>> -- John
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 5/3/2017 5:09 PM, Hugh Cayless wrote:
>>>>> That's exactly what it does. It's just that the behavior
>>>>> of same-document references is prescribed in such a way
>>>>> that they end up resolving to the current document
>>>>> regardless of the value of the @xml:base.
>>>>>
>>>>> Put another way, @xml:base has an influence on what the
>>>>> client application will retrieve when it dereferences a
>>>>> URI and retrieves the referenced document, but in the case
>>>>> of same-document references no such retrieval is expected
>>>>> to occur=E2=80=94it's assumed the client already has the do=
cument.
>>>>>
>>>>> On Wed, May 3, 2017 at 4:29 PM, John P. McCaskey
>>>>> <[email protected]
>>>>> <mailto:[email protected]>> wrote:
>>>>>
>>>>> Oh. I thought it obvious they all resolved the same.
>>>>>
>>>>> I think the same about this one. You think otherwise?
>>>>>
>>>>> <div xml:base=3D"http://www.myteiproject.com/"
>>>>> <http://www.myteiproject.com/> <div
>>>>> xml:base=3D"images/"> <div> <graphic url=3D"logo.jpg">
>>>>> </div> <div xml:base=3D"http://www.dictionary.com/words=
/
>>>>> <http://dictionary.com/words/>"> <p xml:base=3D"a.html"=
>
>>>>> <ref target=3D"#apple">apple</ref> </p> </div> </div>
>>>>> </div>
>>>>>
>>>>> I didn=E2=80=99t think xml:base had any necessary relat=
ion to
>>>>> the current document. I thought in XML (not HTML), it
>>>>> just sets a path for URIs below it.
>>>>>
>>>>> --=20
>>>>>
>>>>> On 5/3/2017 3:42 PM, Hugh Cayless wrote:
>>>>>> Well, we don't know about the third one, except that
>>>>>> it points to whatever element *in the same document*
>>>>>> has the @xml:id "apple". When an application attempts
>>>>>> to dereference it, it should make the URI in @ref
>>>>>> absolute and check it against the base
>>>>>> (http://www.dictionary.com/words/a.html
>>>>>> <http://www.dictionary.com/words/a.html>), discover
>>>>>> they are identical, decide it doesn't need to fetch
>>>>>> anything, and go looking in the current document for
>>>>>> the element with the id "apple".
>>>>>> On Wed, May 3, 2017 at 3:27 PM, John P. McCaskey
>>>>>> <[email protected]
>>>>>> <mailto:[email protected]>> wrote:
>>>>>>
>>>>>> Are people proposing that these targets do not
>>>>>> all resolve to the same
>>>>>> http://www.dictionary.com/words/a.html#apple
>>>>>> <http://www.dictionary.com/words/a.html#apple>?
>>>>>> <div xml:base=3D"http://www.dictionary.com/"
>>>>>> <http://www.dictionary.com/>> <p
>>>>>> xml:base=3D"words/"> <ref
>>>>>> target=3D"a.html#apple">apple</ref> </p> </div>
>>>>>> <div xml:base=3D"http://www.dictionary.com/words/"
>>>>>> <http://www.dictionary.com/words/>> <p
>>>>>> xml:base=3D"a.html"> <ref
>>>>>> target=3D"#apple">apple</ref> </p> </div> <div
>>>>>> xml:base=3D"http://www.dictionary.com/words/a.html=
"
>>>>>> <http://www.dictionary.com/words/a.html>> <p>
>>>>>> <ref target=3D"#apple">apple</ref> </p> </div> <di=
v
>>>>>> xml:base=3D"http://www.dictionary.com/"
>>>>>> <http://www.dictionary.com/>> <p> <ref
>>>>>> target=3D"words/a.html#apple">apple</ref> </p>
>>>>>> </div>--
>>>>>>
--------------86A46EBA1F8CCE9B2CA56A17
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Ty=
pe">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<p><font size=3D"-1">What is the short bottom-line guidance for
someone trying to encode a document? Is it this?<br>
</font></p>
<blockquote>
<p><font size=3D"-1">To point inside a TEI document, as for
@rendition, use pointers of the form #destination. Any later
changes to <a class=3D"moz-txt-link-freetext" href=3D"xml:base"=
>xml:base</a> values will not mess up your internal #
pointers.<br>
</font></p>
<p><font size=3D"-1">Don=E2=80=99t try to point outside your TEI do=
cument by
using <a class=3D"moz-txt-link-freetext" href=3D"xml:base">xml:=
base</a> plus a #destination in the pointer attribute.
No <a class=3D"moz-txt-link-freetext" href=3D"xml:base">xml:bas=
e</a> attribute will be prepended to a pointer that
begins with a #.</font></p>
</blockquote>
<p><font size=3D"-1">Even if I and others find that idiosyncratic and
surprising, it=E2=80=99s unambiguous, has practical benefits, req=
uires
no knowledge of RFCs or W3C specs, is easy to articulate, and is
easy to encode to.</font></p>
<p><font size=3D"-1">John<br>
</font></p>
<p><font size=3D"-1"><br>
</font></p>
<p><font size=3D"-1"><br>
</font></p>
<div class=3D"moz-cite-prefix">On 5/4/2017 2:28 PM, Hugh Cayless
wrote:<br>
</div>
<blockquote
cite=3D"mid:[email protected]=
ail.com"
type=3D"cite">
<div dir=3D"ltr">That's a rather favorable interpretation on your
part. One person agrees with you without elucidating, 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.=C2=A0
<div><br>
</div>
<div>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.=C2=A0</div>
<div><br>
</div>
<div>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 @<a class=3D"moz-txt-link-freetex=
t" href=3D"xml:base">xml:base</a>. 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.</div>
<div><br>
</div>
<div>For what it's worth, modern web browsers seem to agree with
your interpretation (mutatis mutandis=E2=80=94HTML base is not
@<a class=3D"moz-txt-link-freetext" href=3D"xml:base">xml:base<=
/a>). 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]</div>
<div><br>
</div>
<div>To further complicate matters, the author of RFC 3986, Roy
Fielding, has said that using @<a class=3D"moz-txt-link-freetex=
t" href=3D"xml:base">xml:base</a> in the way you
propose, i.e. to enable shorthand references rather than to
set a canonical URI for the current document,=C2=A0is abusive.[=
2]</div>
<div><br>
</div>
<div>Given all this, I still agree with Michael
Sperberg-McQueen's fuller explication of the issues at hand. I
would interpret same-document references as pointing to the
current document, with the caveat that there might be, now or
in the future, certain pointer attributes or element/attribute
combinations that mandate a retrieval action. Such a retrieval
would necessarily use whatever base was defined for the URI in
question.</div>
<div><br>
</div>
<div>References:</div>
<div>1.=C2=A0<a moz-do-not-send=3D"true"
href=3D"http://w3future.com/weblog/2005/01/13.xml#stillBugsInTheImplement=
ationOfHtmlHyperlinks">http://w3future.com/weblog/2005/01/13.xml#stillBug=
sInTheImplementationOfHtmlHyperlinks</a></div>
<div>2. <a moz-do-not-send=3D"true"
href=3D"http://w3future.com/weblog/2005/08/14.xml#howToUseBas=
eUris">http://w3future.com/weblog/2005/08/14.xml#howToUseBaseUris</a>=C2=A0=
</div>
</div>
<div class=3D"gmail_extra"><br>
<div class=3D"gmail_quote">On Thu, May 4, 2017 at 10:16 AM, John
P. McCaskey <span dir=3D"ltr"><<a moz-do-not-send=3D"true"
href=3D"mailto:[email protected]" target=3D"_blank">=
[email protected]</a>></span>
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<p><font size=3D"-1">I asked about this over at XML-DEV, <a
moz-do-not-send=3D"true"
href=3D"http://lists.xml.org/archives/xml-dev/201705/=
msg00008.html"
target=3D"_blank">http://lists.xml.org/archives/<wbr>=
xml-dev/201705/msg00008.html</a>.</font></p>
<p><font size=3D"-1">Opinion there is with me and opposite
the majority here.<br>
</font></p>
<p><font size=3D"-1">Readers there don=E2=80=99t seem to th=
ink there
is anything to debate. I got one short answer and one
dismissive comment about =E2=80=9Dquestions that simple=
.=E2=80=9D
Someone take a look and be sure I didn=E2=80=99t word m=
y
question unfairly.<br>
</font></p>
<font size=3D"-1">Whichever interpretation TEI adopts,
sounds like it should be documented in the Guidelines or
a note somewhere.<br>
<br>
If the McCaskey/XML-DEV interpretation is adopted, the
GitHub issue I posted about @rendition stands. If not,
that issue goes away.<span class=3D"HOEnZb"><font
color=3D"#888888"><br>
</font></span></font><span class=3D"HOEnZb"><font
color=3D"#888888">
<p><font size=3D"-1">John<br>
</font></p>
</font></span>
<div>
<div class=3D"h5">
<p><font size=3D"-1"><br>
</font></p>
<br>
<div class=3D"m_1517433518565409704moz-cite-prefix">On
5/3/2017 8:03 PM, Hugh Cayless wrote:<br>
</div>
<blockquote type=3D"cite">
<div>Those are the cards we've been dealt, yeah.=C2=A0=
<br>
<br>
Sent from my phone.=C2=A0</div>
<div><br>
On May 3, 2017, at 19:53, John P. McCaskey <<a
moz-do-not-send=3D"true"
href=3D"mailto:[email protected]"
target=3D"_blank">[email protected]</a>>=
;
wrote:<br>
<br>
</div>
<blockquote type=3D"cite">
<div>
<p><font size=3D"-1">So, bottom line: A standalon=
e
fragment identifier refers to the loaded
document and all the <a
moz-do-not-send=3D"true"
class=3D"m_1517433518565409704moz-txt-link-=
freetext">xml:base</a>
values above it in the hierarchy are
irrelevant. Encoders cannot use <a
moz-do-not-send=3D"true"
class=3D"m_1517433518565409704moz-txt-link-=
freetext">xml:base</a>
to direct a standalone #fragment value to a
location outside the loaded document.</font><=
/p>
<p><font size=3D"-1">Is that right?</font></p>
<p><font size=3D"-1">--<br>
</font></p>
<p><br>
</p>
<div
class=3D"m_1517433518565409704moz-cite-prefix">=
<font
size=3D"-1">On 5/3/2017 6:20 PM, Hugh Cayless
wrote:</font><br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr"><font size=3D"-1">No. This
clarifies the expected behavior when
(e.g.) you have @<a moz-do-not-send=3D"true=
"
class=3D"m_1517433518565409704moz-txt-link-freetext">xml:base=3D</a>"#fra=
g".
It says nothing whatever about <p
rendition=3D"#foo">. I don't think these
specifications interact in the way you're
positing. Quite the opposite.</font></div>
<div class=3D"gmail_extra"><font size=3D"-1"><b=
r>
</font>
<div class=3D"gmail_quote"><font size=3D"-1">=
On
Wed, May 3, 2017 at 6:13 PM, John P.
McCaskey <span dir=3D"ltr"><<a
moz-do-not-send=3D"true"
href=3D"mailto:[email protected]=
om"
target=3D"_blank">mailbox@johnmccaske=
y.com</a>></span>
wrote:</font><br>
<blockquote class=3D"gmail_quote"
style=3D"margin:0 0 0 .8ex;border-left:1p=
x
#ccc solid;padding-left:1ex">
<div bgcolor=3D"#FFFFFF" text=3D"#000000"=
>
<p>The special behavior of
same-document references in RFC 3986
is disavowed by W3C: <br>
</p>
<span>
<blockquote>
<p><font size=3D"-2">4.4
Interpretation of
same-document references<br>
<br>
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 <b=
><a
moz-do-not-send=3D"true"
class=3D"m_1517433518565409=
704m_-3680229684002831364moz-txt-link-freetext">xml:base</a>
attribute does not</b> <b>inv=
olve
</b>dereferencing, and XML
Base processors should resolve
them in the usual way. In
particular, <a
moz-do-not-send=3D"true"
class=3D"m_151743351856540970=
4m_-3680229684002831364moz-txt-link-freetext">xml:base=3D</a>""
does not reset the base URI to
that of the containing
document.<br>
<br>
Note:<br>
<br>
Some existing processors do
treat these <a
moz-do-not-send=3D"true"
class=3D"m_151743351856540970=
4m_-3680229684002831364moz-txt-link-freetext">xml:base</a>
values as resetting the base
URI to that of the containing
document, so the use of such
values is strongly
discouraged.</font><br>
</p>
</blockquote>
</span> This says:<br>
<blockquote>RFC 3986 defines special
=E2=80=9Cdereferencing=E2=80=9D of em=
pty 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. <br>
</blockquote>
<br>
A note has:<br>
<blockquote><font size=3D"-2">5. The
meanings of <a
moz-do-not-send=3D"true"
class=3D"m_1517433518565409704m_-=
3680229684002831364moz-txt-link-freetext">xml:base=3D</a>""
and <a moz-do-not-send=3D"true"
class=3D"m_1517433518565409704m_-=
3680229684002831364moz-txt-link-freetext">xml:base=3D</a>"#frag"
have been clarified;</font><br>
</blockquote>
This says: <br>
<blockquote>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.<br>
</blockquote>
No?<span
class=3D"m_1517433518565409704HOEnZb"=
><font
color=3D"#888888"><br>
<br>
-- John</font></span>
<div>
<div class=3D"m_1517433518565409704h5=
"><br>
<br>
<br>
<br>
<br>
<br>
<div
class=3D"m_1517433518565409704m_-=
3680229684002831364moz-cite-prefix">On
5/3/2017 5:09 PM, Hugh Cayless
wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">That's exactly
what it does. It's just that
the behavior of same-document
references is prescribed in
such a way that they end up
resolving to the current
document regardless of the
value of the @<a
moz-do-not-send=3D"true"
class=3D"m_151743351856540970=
4m_-3680229684002831364moz-txt-link-freetext">xml:base</a>.
<div><br>
</div>
<div>Put another way, @<a
moz-do-not-send=3D"true"
class=3D"m_1517433518565409=
704m_-3680229684002831364moz-txt-link-freetext">xml:base</a>
has an influence on what the
client application will
retrieve when it
dereferences a URI and
retrieves the referenced
document, but in the case of
same-document references no
such retrieval is expected
to occur=E2=80=94it's assumed=
the
client already has the
document.</div>
</div>
<div class=3D"gmail_extra"><br>
<div class=3D"gmail_quote">On
Wed, May 3, 2017 at 4:29 PM,
John P. McCaskey <span
dir=3D"ltr"><<a
moz-do-not-send=3D"true"
href=3D"mailto:mailbox@jo=
hnmccaskey.com"
target=3D"_blank">mailbox=
@johnmccaskey.com</a>></span>
wrote:<br>
<blockquote
class=3D"gmail_quote"
style=3D"margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div bgcolor=3D"#FFFFFF"
text=3D"#000000">
<p><font size=3D"-1">Oh. =
I
thought it obvious
they all resolved
the same. <br>
</font></p>
<p><font size=3D"-1">I
think the same about
this one. You think
otherwise?<br>
</font></p>
<pre><font size=3D"-1">&l=
t;div <a moz-do-not-send=3D"true" class=3D"m_1517433518565409704m_-368022=
9684002831364m_-7516606003097729134moz-txt-link-freetext">xml:base=3D</a>=
<a moz-do-not-send=3D"true" class=3D"m_1517433518565409704m_-368022968400=
2831364m_-7516606003097729134moz-txt-link-rfc2396E" href=3D"http://www.my=
teiproject.com/" target=3D"_blank">"http://www.myteiproj<wbr>ect.com/"</a=
>
<div <a moz-do-not-send=3D"true" class=3D"m_1517433518565409704m_-36=
80229684002831364m_-7516606003097729134moz-txt-link-freetext">xml:base=3D=
</a>"images/">
<div>
<graphic url=3D"logo.jpg">
</div>
<div <a moz-do-not-send=3D"true" class=3D"m_1517433518565409704m_-=
3680229684002831364m_-7516606003097729134m_-1417418399130310658moz-txt-li=
nk-freetext">xml:base=3D</a><span class=3D"m_1517433518565409704m_-368022=
9684002831364m_-7516606003097729134m_-1417418399130310658moz-txt-link-rfc=
2396E">"<a moz-do-not-send=3D"true" class=3D"m_1517433518565409704m_-3680=
229684002831364m_-7516606003097729134moz-txt-link-freetext" href=3D"http:=
//www" target=3D"_blank">http://www</a>.<a moz-do-not-send=3D"true" href=3D=
"http://dictionary.com/words/" target=3D"_blank">dictionar<wbr>y.com/word=
s/</a>"</span>>
<p <a moz-do-not-send=3D"true" class=3D"m_1517433518565409704m_-=
3680229684002831364m_-7516606003097729134m_-1417418399130310658moz-txt-li=
nk-freetext">xml:base=3D</a>"a.html">
<ref target=3D"#apple">apple</ref>
</p>
</div>
</div>
</div>=20
</font></pre><p><font size=3D"-1">I didn=E2=80=99t think <a moz-do-not-se=
nd=3D"true" class=3D"m_1517433518565409704m_-3680229684002831364m_-751660=
6003097729134moz-txt-link-freetext">xml:base</a> had any necessary relati=
on to the current document. I thought in XML (not HTML), it just sets a p=
ath for URIs below it.</font></p><p><font size=3D"-1">--
</font></p><div><div class=3D"m_1517433518565409704m_-3680229684002831364=
h5">
<div class=3D"m_1517433518565409704m_-3680229684002831364m_-7516606003097=
729134moz-cite-prefix">On 5/3/2017 3:42 PM, Hugh Cayless wrote:
</div><blockquote type=3D"cite"><div dir=3D"ltr">Well, we don't know abou=
t the third one, except that it points to whatever element *in the same d=
ocument* has the @<a moz-do-not-send=3D"true" class=3D"m_1517433518565409=
704m_-3680229684002831364m_-7516606003097729134moz-txt-link-freetext">xml=
:id</a> "apple". When an application attempts to dereference it, it shoul=
d make the URI in @ref absolute and check it against the base (<a moz-do-=
not-send=3D"true" class=3D"m_1517433518565409704m_-3680229684002831364m_-=
7516606003097729134gmail-m_-1417418399130310658moz-txt-link-rfc2396E" hre=
f=3D"http://www.dictionary.com/words/a.html" style=3D"white-space:pre-wra=
p" target=3D"_blank">http://www.dictionary.com/wor<wbr>ds/a.html</a>), di=
scover they are identical, decide it doesn't need to fetch anything, and =
go looking in the current document for the element with the id "apple".</=
div><div class=3D"gmail_extra">
<div class=3D"gmail_quote">On Wed, May 3, 2017 at 3:27 PM, John P. McCask=
ey <span dir=3D"ltr"><<a moz-do-not-send=3D"true" href=3D"mailto:mailb=
[email protected]" target=3D"_blank">[email protected]</a>></=
span> wrote:
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<pre><font size=3D"-1">Are people proposing that these targets do not=
all resolve=20
to the same <a moz-do-not-send=3D"true" class=3D"m_1517433518565409704m_-=
3680229684002831364m_-7516606003097729134m_-1417418399130310658moz-txt-li=
nk-freetext" href=3D"http://www.dictionary.com/words/a.html#apple" target=
=3D"_blank">http://www.dictionary.com/word<wbr>s/a.html#apple</a>?
</font><font size=3D"-1"><div <a moz-do-not-send=3D"true" class=3D"m_1=
517433518565409704m_-3680229684002831364m_-7516606003097729134m_-14174183=
99130310658moz-txt-link-freetext">xml:base=3D</a><a moz-do-not-send=3D"tr=
ue" class=3D"m_1517433518565409704m_-3680229684002831364m_-75166060030977=
29134m_-1417418399130310658moz-txt-link-rfc2396E" href=3D"http://www.dict=
ionary.com/" target=3D"_blank">"http://www.dictionar<wbr>y.com/"</a>>
<p <a moz-do-not-send=3D"true" class=3D"m_1517433518565409704m_-36=
80229684002831364m_-7516606003097729134m_-1417418399130310658moz-txt-link=
-freetext">xml:base=3D</a>"words/">
<ref target=3D"a.html#apple">apple</r<wbr>ef>
</p>
</div>
<div <a moz-do-not-send=3D"true" class=3D"m_1517433518565409704m_-3680=
229684002831364m_-7516606003097729134m_-1417418399130310658moz-txt-link-f=
reetext">xml:base=3D</a><a moz-do-not-send=3D"true" class=3D"m_1517433518=
565409704m_-3680229684002831364m_-7516606003097729134m_-14174183991303106=
58moz-txt-link-rfc2396E" href=3D"http://www.dictionary.com/words/" target=
=3D"_blank">"http://www.dictionar<wbr>y.com/words/"</a>>
<p <a moz-do-not-send=3D"true" class=3D"m_1517433518565409704m_-36=
80229684002831364m_-7516606003097729134m_-1417418399130310658moz-txt-link=
-freetext">xml:base=3D</a>"a.html">
<ref target=3D"#apple">apple</ref>
</p>
</div>
<div <a moz-do-not-send=3D"true" class=3D"m_1517433518565409704m_-3680=
229684002831364m_-7516606003097729134m_-1417418399130310658moz-txt-link-f=
reetext">xml:base=3D</a><a moz-do-not-send=3D"true" class=3D"m_1517433518=
565409704m_-3680229684002831364m_-7516606003097729134m_-14174183991303106=
58moz-txt-link-rfc2396E" href=3D"http://www.dictionary.com/words/a.html" =
target=3D"_blank">"http://www.dictionar<wbr>y.com/words/a.html"</a>>
<p>
<ref target=3D"#apple">apple</ref>
</p>
</div>
<div <a moz-do-not-send=3D"true" class=3D"m_1517433518565409704m_-3680=
229684002831364m_-7516606003097729134m_-1417418399130310658moz-txt-link-f=
reetext">xml:base=3D</a><a moz-do-not-send=3D"true" class=3D"m_1517433518=
565409704m_-3680229684002831364m_-7516606003097729134m_-14174183991303106=
58moz-txt-link-rfc2396E" href=3D"http://www.dictionary.com/" target=3D"_b=
lank">"http://www.dictionar<wbr>y.com/"</a>>
<p>
<ref target=3D"words/a.html#apple">ap<wbr>ple</ref>
</p>
</div></font><span class=3D"m_1517433518565409704m_-368022968400283=
1364m_-7516606003097729134HOEnZb"><font color=3D"#888888">
<font size=3D"-1">
--=20
</font></font></span></pre>
</div>
</blockquote></div>
</div>
</blockquote>
</div></div></div></blockquote></div>
</div>
</blockquote>
</div></div></div></blockquote></div>
</div>
</blockquote>
</div></blockquote>
</blockquote>
</div></div></div></blockquote></div>
</div>
</blockquote>
</body></html>
--------------86A46EBA1F8CCE9B2CA56A17--