Re: @xml:base with @rendition (and maybe other pointers)
Hugh Cayless <[email protected]> Thu, 4 May 2017 14:28:37 -0400
| Newsgroups | gmane.text.tei.general |
|---|---|
| Message-ID | <CAObhq+dUbzOvPAJbmukNgLD05y8kSPtP5GaAP+18-0_Pxx=JpQ@mail.gmail.com> |
--001a114ed840110c6e054eb6f1b7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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. 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. 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. 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 fa= r 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] 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] 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. References: 1. http://w3future.com/weblog/2005/01/13.xml#stillBugsInTheImplementationOfHtm= lHyperlinks 2. http://w3future.com/weblog/2005/08/14.xml#howToUseBaseUris On Thu, May 4, 2017 at 10:16 AM, John P. McCaskey <[email protected]= > wrote: > I asked about this over at XML-DEV, 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 debate. I = got one > short answer and one dismissive comment about =E2=80=9Dquestions that sim= ple.=E2=80=9D > Someone take a look and be sure I didn=E2=80=99t word my question unfairl= y. > 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 away. > > 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]> > 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 thes= e > 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]= m > > wrote: > >> The special behavior of same-document references in RFC 3986 is disavowe= d >> by W3C: >> >> 4.4 Interpretation of same-document references >> >> RFC 3986 defines certain relative URI references, in particular the empt= y >> 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 *der= eferencing, >> 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 i= s >> strongly discouraged. >> >> This says: >> >> RFC 3986 defines special =E2=80=9Cdereferencing=E2=80=9D of empty string= s 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 reso= lve >> empty strings and #fragments as specified in the W3C Recommendation abov= e. >> And those of you who did carry that stuff over from 3986 to XML-land, sh= ame >> 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 clarif= ied; >> >> 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-documen= t >> 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 h= as the >> document. >> >> On Wed, May 3, 2017 at 4:29 PM, John P. McCaskey < >> [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/"> >>> <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 relation to the curre= nt >>> document. I thought in XML (not HTML), it just sets a path for URIs bel= ow >>> it. >>> >>> -- >>> 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 @r= ef >>> absolute and check it against the base (http://www.dictionary.com/wor >>> ds/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]> wrote: >>>> >>>> Are people proposing that these targets do not all resolve >>>> to the same http://www.dictionary.com/words/a.html#apple? >>>> <div xml:base=3D"http://www.dictionary.com/" <http://www.dictionary.co= m/>> >>>> <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.diction= ary.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.d= ictionary.com/words/a.html>> >>>> <p> >>>> <ref target=3D"#apple">apple</ref> >>>> </p> >>>> </div> >>>> >>>> <div xml:base=3D"http://www.dictionary.com/" <http://www.dictionary.co= m/>> >>>> <p> >>>> <ref target=3D"words/a.html#apple">apple</ref> >>>> </p> >>>> </div> >>>> -- >>>> >>>> --001a114ed840110c6e054eb6f1b7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">That's a rather favorable interpretation on your part.= One person agrees with you without elucidating, one says this discussion h= as jumped the shark (which is fair), and the third (Michael Kay) gives a fu= ller answer which adds up to "it depends". Michael Kay is quite c= orrect that in the context where a document retrieval is *expected* to occu= r, 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 attrib= utes or element/attribute combinations which are defined as *forcing* a ret= rieval 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 on= e 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 o= ught 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 m= ight break them.</div><div><br></div><div>For what it's worth, modern w= eb 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 c= ompatibility with IE 4(!).[1]</div><div><br></div><div>To further complicat= e matters, the author of RFC 3986, Roy Fielding, has said that using @xml:b= ase 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-McQ= ueen's fuller explication of the issues at hand. I would interpret same= -document references as pointing to the current document, with the caveat t= hat there might be, now or in the future, certain pointer attributes or ele= ment/attribute combinations that mandate a retrieval action. Such a retriev= al would necessarily use whatever base was defined for the URI in question.= </div><div><br></div><div>References:</div><div>1.=C2=A0<a href=3D"http://w= 3future.com/weblog/2005/01/13.xml#stillBugsInTheImplementationOfHtmlHyperli= nks">http://w3future.com/weblog/2005/01/13.xml#stillBugsInTheImplementation= OfHtmlHyperlinks</a></div><div>2. <a href=3D"http://w3future.com/weblog/200= 5/08/14.xml#howToUseBaseUris">http://w3future.com/weblog/2005/08/14.xml#how= ToUseBaseUris</a>=C2=A0</div></div><div class=3D"gmail_extra"><br><div clas= s=3D"gmail_quote">On Thu, May 4, 2017 at 10:16 AM, John P. McCaskey <span d= ir=3D"ltr"><<a href=3D"mailto:[email protected]" target=3D"_blank= ">[email protected]</a>></span> wrote:<br><blockquote class=3D"gm= ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le= ft:1ex"> =20 =20 =20 <div bgcolor=3D"#FFFFFF" text=3D"#000000"> <p><font size=3D"-1">I asked about this over at XML-DEV, <a href=3D"htt= p://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 think 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 my 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"> =20 <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 href=3D"mailto:ma= [email protected]" target=3D"_blank">[email protected]</a>> wrote:<br> <br> </div> <blockquote type=3D"cite"> <div> =20 <p><font size=3D"-1">So, bottom line: A standalone fragment identifier refers to the loaded document and all the <a class= =3D"m_1517433518565409704moz-txt-link-freetext">xml:base</a> values above i= t in the hierarchy are irrelevant. Encoders cannot use <a class=3D"m_1= 517433518565409704moz-txt-link-freetext">xml:base</a> to direct a standalon= e #fragment value to a location outside the loaded document.</f= ont></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 class=3D"m_15174= 33518565409704moz-txt-link-freetext">xml:base=3D</a>"#frag". It s= ays nothing whatever about <p rendition=3D"#foo">. I do= n'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"><br> </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 href=3D"mailto:[email protected]" target=3D"_blank">mailbox@johnmc= caskey.com</a>></span> wrote:</font><br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e= x;border-left:1px #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 class=3D"m_1517433518565409704m_-36= 80229684002831364moz-txt-link-freetext">xml:base</a> attribute does not</b> <b>involve </b>derefer= encing, and XML Base processors should resolve them in the usual way. In particular, <a class=3D"m_= 1517433518565409704m_-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 clas= s=3D"m_1517433518565409704m_-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=9Cdereferen= cing=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. <br> </blockquote> <br> A note has:<br> <blockquote><font size=3D"-2">5. The meanings of <a cla= ss=3D"m_1517433518565409704m_-3680229684002831364moz-txt-link-freetext">xml= :base=3D</a>"" and <a class=3D"m_1517433518565409704m_-36802296840= 02831364moz-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 co= lor=3D"#888888"><br> <br> -- John</font></span> <div> <div class=3D"m_1517433518565409704h5"><br> <br> <br> <br> <br> <br> <div class=3D"m_1517433518565409704m_-3680229684002= 831364moz-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-documen= t references is prescribed in such a way that they end up resolving to the current document regardless of the value of the @<a cla= ss=3D"m_1517433518565409704m_-3680229684002831364moz-txt-link-freetext">xml= :base</a>. <div><br> </div> <div>Put another way, @<a class=3D"m_1517433518= 565409704m_-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 href=3D"mailto:[email protected]" target=3D"_blank">mailbox= @johnmccaskey.com</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"ma= rgin: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"><div <a class= =3D"m_1517433518565409704m_-3680229684002831364m_-7516606003097729134moz-tx= t-link-freetext">xml:base=3D</a><a class=3D"m_1517433518565409704m_-3680229= 684002831364m_-7516606003097729134moz-txt-link-rfc2396E" href=3D"http://www= .myteiproject.com/" target=3D"_blank">"http://www.myteiproj<wbr>ect.co= m/"</a> <div <a class=3D"m_1517433518565409704m_-3680229684002831364m_-7516606= 003097729134moz-txt-link-freetext">xml:base=3D</a>"images/"> <div> <graphic url=3D"logo.jpg"> </div> <div <a class=3D"m_1517433518565409704m_-3680229684002831364m_-75166= 06003097729134m_-1417418399130310658moz-txt-link-freetext">xml:base=3D</a><= span class=3D"m_1517433518565409704m_-3680229684002831364m_-751660600309772= 9134m_-1417418399130310658moz-txt-link-rfc2396E">"<a class=3D"m_151743= 3518565409704m_-3680229684002831364m_-7516606003097729134moz-txt-link-freet= ext" href=3D"http://www" target=3D"_blank">http://www</a>.<a href=3D"http:/= /dictionary.com/words/" target=3D"_blank">dictionar<wbr>y.com/words/</a>&qu= ot;</span>> <p <a class=3D"m_1517433518565409704m_-3680229684002831364m_-75166= 06003097729134m_-1417418399130310658moz-txt-link-freetext">xml:base=3D</a>&= quot;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 class=3D"m_1517= 433518565409704m_-3680229684002831364m_-7516606003097729134moz-txt-link-fre= etext">xml:base</a> had any necessary relation to the current document. I t= hought in XML (not HTML), it just sets a path for URIs below it.</font></p>= <p><font size=3D"-1">-- </font></p><div><div class=3D"m_1517433518565409704m_-3680229684002831364h5= "> <div class=3D"m_1517433518565409704m_-3680229684002831364m_-751660600309772= 9134moz-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 ab= out the third one, except that it points to whatever element *in the same d= ocument* has the @<a class=3D"m_1517433518565409704m_-3680229684002831364m_= -7516606003097729134moz-txt-link-freetext">xml:id</a> "apple". Wh= en an application attempts to dereference it, it should make the URI in @re= f absolute and check it against the base (<a class=3D"m_1517433518565409704= m_-3680229684002831364m_-7516606003097729134gmail-m_-1417418399130310658moz= -txt-link-rfc2396E" href=3D"http://www.dictionary.com/words/a.html" style= =3D"white-space:pre-wrap" target=3D"_blank">http://www.dictionary.com/wor<w= br>ds/a.html</a>), discover they are identical, decide it doesn't need = to fetch anything, and go looking in the current document for the element w= ith 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. McCaskey= <span dir=3D"ltr"><<a href=3D"mailto:[email protected]" target= =3D"_blank">[email protected]</a>></span> wrote: <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #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 a= ll resolve=20 to the same <a class=3D"m_1517433518565409704m_-3680229684002831364m_-75166= 06003097729134m_-1417418399130310658moz-txt-link-freetext" href=3D"http://w= ww.dictionary.com/words/a.html#apple" target=3D"_blank">http://www.dictiona= ry.com/word<wbr>s/a.html#apple</a>? </font><font size=3D"-1"><div <a class=3D"m_1517433518565409704m_-368022= 9684002831364m_-7516606003097729134m_-1417418399130310658moz-txt-link-freet= ext">xml:base=3D</a><a class=3D"m_1517433518565409704m_-3680229684002831364= m_-7516606003097729134m_-1417418399130310658moz-txt-link-rfc2396E" href=3D"= http://www.dictionary.com/" target=3D"_blank">"http://www.dictionar<wb= r>y.com/"</a>> <p <a class=3D"m_1517433518565409704m_-3680229684002831364m_-7516606= 003097729134m_-1417418399130310658moz-txt-link-freetext">xml:base=3D</a>&qu= ot;words/"> <ref target=3D"a.html#apple">apple</r<wbr>ef> </p> </div> <div <a class=3D"m_1517433518565409704m_-3680229684002831364m_-751660600= 3097729134m_-1417418399130310658moz-txt-link-freetext">xml:base=3D</a><a cl= ass=3D"m_1517433518565409704m_-3680229684002831364m_-7516606003097729134m_-= 1417418399130310658moz-txt-link-rfc2396E" href=3D"http://www.dictionary.com= /words/" target=3D"_blank">"http://www.dictionar<wbr>y.com/words/"= ;</a>> <p <a class=3D"m_1517433518565409704m_-3680229684002831364m_-7516606= 003097729134m_-1417418399130310658moz-txt-link-freetext">xml:base=3D</a>&qu= ot;a.html"> <ref target=3D"#apple">apple</ref> </p> </div> <div <a class=3D"m_1517433518565409704m_-3680229684002831364m_-751660600= 3097729134m_-1417418399130310658moz-txt-link-freetext">xml:base=3D</a><a cl= ass=3D"m_1517433518565409704m_-3680229684002831364m_-7516606003097729134m_-= 1417418399130310658moz-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 class=3D"m_1517433518565409704m_-3680229684002831364m_-751660600= 3097729134m_-1417418399130310658moz-txt-link-freetext">xml:base=3D</a><a cl= ass=3D"m_1517433518565409704m_-3680229684002831364m_-7516606003097729134m_-= 1417418399130310658moz-txt-link-rfc2396E" href=3D"http://www.dictionary.com= /" target=3D"_blank">"http://www.dictionar<wbr>y.com/"</a>> <p> <ref target=3D"words/a.html#apple">ap<wbr>ple</r= ef> </p> </div></font><span class=3D"m_1517433518565409704m_-36802296840028313= 64m_-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><br></div> --001a114ed840110c6e054eb6f1b7--