Re: @xml:base with @rendition (and maybe other pointers)
Hugh Cayless <[email protected]> Thu, 4 May 2017 17:07:00 -0400
| Newsgroups | gmane.text.tei.general |
|---|---|
| Message-ID | <CAObhq+eAAYAYPfctYys4JvOaWgPtd94xU1a6FECti8TmYUViYQ@mail.gmail.com> |
--001a113e228a7633b4054eb9279a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, May 4, 2017 at 4:32 PM, C. M. Sperberg-McQueen < [email protected]> wrote: > > > > 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 retriev= al > is *expected* to occur, the URI would indeed be computed with reference t= o > its base and fetched. > > The URI is *always* computed with reference to its base. > Right. It's the "and fetched" part that's crucial. In a context where retrieval is forced, if the base is different from the document URI you'd expect to end up somewhere else. > > 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 duri= ng > 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 b= e > avoided. The 'should' here means that 3986 recommends that new retrieval= s > be avoided, but does not forbid new retrievals; if conforming processors = or > specs have good reason for launching new retrievals, that's not a violati= on > 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 curre= nt > document.) > > > > > 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 ther= e > 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? > Well, from my selfish perspective, "breakage" mainly means we've got to go all over the Guidelines and add notes to the effect that '#fragment' pointers may behave differently if @xml:base is set. To an extent, wanting to avoid this is sheer laziness on my part. But I'm also convinced that <tei:ref target=3D"#foo"> in P5 is intended to mean the same thing that <re= f target=3D"foo"> did in P4, when the value of @target was IDREFS rather than teidata.pointer+ (I believe you mentioned this earlier), and that the introduction of @xml:base was not intended to affect that meaning. I think we're better off assuming that same-document references are referring to the document that contains them. > > 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 wi= ll > not break any? Or is it the case that one interpretation will break some > URI references, and a different interpretation will break others? > > 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 documen= ts > and not breaking them, but between breaking those belonging to one projec= t > 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? > > 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=9C > http://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 g= o to =E2=80=A6 where? > In my brief experimentation, Chrome, Firefox, and Safari will all load http://example.org/base.html#quovadis in this case, rather than scroll to the element with id=3D"quovadis" in the current page. > > 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 constitu= te > a decision on the part of the browser about which of the two possible pat= hs > to a given resource it should take? > > I think it means the browser implementers decided to favor stability over technical correctness. > > > To further complicate matters, the author of RFC 3986, Roy Fielding, ha= s > said that using @xml:base in the way you propose, i.e. to enable shorthan= d > references rather than to set a canonical URI for the current document, i= s > abusive.[2] > > Thank you for that reference. > > 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 t= he > document, and that using xml:base or html:base to shorten references whic= h > 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 simp= le 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 locat= ions in the > current document. These will always be same-document references within t= he > 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/ent= ries/=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.h= tml=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 sa= me-document > reference, it will ALSO always be a reference to the given fragment in th= e > 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 wi= th fire: > RFC 3986 says =E2=80=9C#fragment=E2=80=9D =E2=80=9Cshould=E2=80=9D be der= eferenced 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. > I think this is perfectly reasonable. I believe we're justified in saying what the TEI expects "#fragment" to mean in the context of a TEI document, but we can't guarantee that some piece of software that processes your document won't make different decisions than we expect. > > > > > References: > > 1. http://w3future.com/weblog/2005/01/13.xml# > stillBugsInTheImplementationOfHtmlHyperlinks > > 2. http://w3future.com/weblog/2005/08/14.xml#howToUseBaseUris > > > ******************************************** > C. M. Sperberg-McQueen > Black Mesa Technologies LLC > [email protected] > http://www.blackmesatech.com > ******************************************** > > --001a113e228a7633b4054eb9279a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo= te">On Thu, May 4, 2017 at 4:32 PM, C. M. Sperberg-McQueen <span dir=3D"ltr= "><<a href=3D"mailto:[email protected]" target=3D"_blank">cmsmcq@= blackmesatech.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote= " style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);= padding-left:1ex"><br> <span class=3D"gmail-"><br> > 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 depend= s". Michael Kay is quite correct that in the context where a document = retrieval is *expected* to occur, the URI would indeed be computed with ref= erence to its base and fetched.<br> <br> </span>The URI is *always* computed with reference to its base.<br></blockq= uote><div><br></div><div>Right. It's the "and fetched" part t= hat's crucial. In a context where retrieval is forced, if the base is d= ifferent from the document URI you'd expect to end up somewhere else.= =C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0= .8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br> Optimizations which produce the same result are, of course, allowed.=C2=A0 = The preceding paragraph is a claim about the meaning of certain language co= nstructs, not a claim about what the CPU and network controller do during e= valuation of an expression by a conforming processor.<br> <br> 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 doc= ument; in consequence no new retrieval is necessary and a new retrieval sho= uld be avoided.=C2=A0 The 'should' here means that 3986 recommends = that new retrievals be avoided, but does not forbid new retrievals; if conf= orming processors or specs have good reason for launching new retrievals, t= hat's not a violation of the rules of 3986.=C2=A0 The XSLT spec defines= the document() function as always launching a new retrieval.=C2=A0 (Note t= hat this does not amount to any claim by the XSLT spec that the relevant re= source is not within the current document.)<br> <span class=3D"gmail-"><br> ><br> > The thing is, I'm not aware of any TEI attributes or element/attri= bute combinations which are defined as *forcing* a retrieval action. I'= d be happy to be corrected if I'm missing any, of course.<br> ><br> > 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, a= nd I'm firmly against anything that might break them.<br> <br> </span>Is it clear what counts as breakage, here?<br></blockquote><div><br>= </div><div>Well, from my selfish perspective, "breakage" mainly m= eans we've got to go all over the Guidelines and add notes to the effec= t that '#fragment' pointers may behave differently if @xml:base is = set. To an extent, wanting to avoid this is sheer laziness on my part. But = I'm also convinced that <tei:ref target=3D"#foo"> in P5= is intended to mean the same thing that <ref target=3D"foo"&g= t; did in P4, when the value of @target was IDREFS rather than teidata.poin= ter+ (I believe you mentioned this earlier), and that the introduction of @= xml:base was not intended to affect that meaning. I think we're better = off assuming that same-document references are referring to the document th= at contains them.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" s= tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad= ding-left:1ex"> <br> If a given interpretation of the URI specs causes some URI references to br= eak (by which I mean: to have an interpretation different from what the enc= oders intended), can we be confident that a contrary interpretation will no= t break any?=C2=A0 Or is it the case that one interpretation will break som= e URI references, and a different interpretation will break others?<br> <br> 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.=C2=A0 The= re is some risk that your choice does not lie between breaking things in TE= I documents and not breaking them, but between breaking those belonging to = one project and breaking those belonging to another project.<br> <span class=3D"gmail-"><br> > For what it's worth, modern web browsers seem to agree with your i= nterpretation (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 dev= elopers back in the day to maintain compatibility with IE 4(!).[1]<br> <br> </span>Can you expound?<br> <br> Do you mean that in an HTML 4.01 or XHTML 1.0 document at <a href=3D"http:/= /example.com/doc.html" rel=3D"noreferrer" target=3D"_blank">http://example.= com/doc.html</a> containing <base href=3D=E2=80=9C<a href=3D"http://exam= ple.org/base.html" rel=3D"noreferrer" target=3D"_blank">http://example.org/= base.<wbr>html</a>=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?<br></blockquote><div><br></div><div>In my brief experimentati= on, Chrome, Firefox, and Safari will all load <a href=3D"http://example.org= /base.html#quovadis">http://example.org/base.html#quovadis</a> in this case= , rather than scroll to the element with id=3D"quovadis" in the c= urrent page.</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px= 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br> I think the two obvious things one might expect to see in the address bar a= fter traversing that link are<br> <br> =C2=A0 =C2=A0 <a href=3D"http://example.com/doc.html#quovadis" rel=3D"noref= errer" target=3D"_blank">http://example.com/doc.html#<wbr>quovadis</a><br> =C2=A0 =C2=A0 <a href=3D"http://example.org/base.html#quovaids" rel=3D"nore= ferrer" target=3D"_blank">http://example.org/base.html#<wbr>quovaids</a><br= > <br> In the first case, this will happen either after a document refresh or with= out a refresh (just scrolling to the place).<br> <br> If a browser shows one of these addresses, does that constitute a claim tha= t the other identifies a different resource?=C2=A0 Or does it only constitu= te a decision on the part of the browser about which of the two possible pa= ths to a given resource it should take?<br> <span class=3D"gmail-"><br></span></blockquote><div>I think it means the br= owser implementers decided to favor stability over technical correctness.</= div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px = 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><spa= n class=3D"gmail-"> <br> > To further complicate matters, the author of RFC 3986, Roy Fielding, h= as said that using @xml:base in the way you propose, i.e. to enable shortha= nd references rather than to set a canonical URI for the current document, = is abusive.[2]<br> <br> </span>Thank you for that reference.<br> <br> 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 UR= I of the document, and that using xml:base or html:base to shorten referenc= es which would otherwise be long is not a scenario worth bending over backw= ards for.=C2=A0 (That is, it seems to me to simplify matters, rather than c= omplicating them.)<br> <br> 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 likel= ihood of unpleasant surprises:<br> <br> =C2=A0 - Use the form =E2=80=9C#fragment=E2=80=9D only for references to lo= cations in the current document.=C2=A0 These will always be same-document r= eferences within the meaning of RFC 3986.<br> =C2=A0 - Use xml:base to set all but the last bit of the URI, but not to se= t a full document URI:=C2=A0 xml:base=3D=E2=80=9C<a href=3D"http://dictiona= ry.example.org/entries/" rel=3D"noreferrer" target=3D"_blank">http://dictio= nary.<wbr>example.org/entries/</a>=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 be= tter than xml:base=3D=E2=80=9C<a href=3D"http://dictionary.example.org/entr= ies/a.html" rel=3D"noreferrer" target=3D"_blank">http://dictionary.<wbr>exa= mple.org/entries/a.html</a>=E2=80=9D with relative referencs to =E2=80=9C#a= pple=E2=80=9D and =E2=80=9C#anodyne=E2=80=9D.=C2=A0 These will never be tak= en to be same-document references.<br> <br> 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 fragme= nt in the resource identified by the base URI.=C2=A0 If that=E2=80=99s not = logically the same as the resource within which the reference occurs, you= =E2=80=99re playing with fire:=C2=A0 RFC 3986 says =E2=80=9C#fragment=E2=80= =9D =E2=80=9Cshould=E2=80=9D be dereferenced without a new retrieval, not t= hat it must be.=C2=A0 Any software will be perfectly within its rights to r= etrieve the base URI and look for the fragment there.<br></blockquote><div>= <br></div><div>I think this is perfectly reasonable. I believe we're ju= stified in saying what the TEI expects "#fragment" to mean in the= context of a TEI document, but we can't guarantee that some piece of s= oftware that processes your document won't make different decisions tha= n we expect.</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px= 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <span class=3D"gmail-im gmail-HOEnZb"><br> ><br> > References:<br> > 1. <a href=3D"http://w3future.com/weblog/2005/01/13.xml#stillBugsInThe= ImplementationOfHtmlHyperlinks" rel=3D"noreferrer" target=3D"_blank">http:/= /w3future.com/weblog/<wbr>2005/01/13.xml#<wbr>stillBugsInTheImplementationO= f<wbr>HtmlHyperlinks</a><br> > 2. <a href=3D"http://w3future.com/weblog/2005/08/14.xml#howToUseBaseUr= is" rel=3D"noreferrer" target=3D"_blank">http://w3future.com/weblog/<wbr>20= 05/08/14.xml#<wbr>howToUseBaseUris</a><br> <br> <br> </span><div class=3D"gmail-HOEnZb"><div class=3D"gmail-h5">****************= **************<wbr>**************<br> C. M. Sperberg-McQueen<br> Black Mesa Technologies LLC<br> <a href=3D"mailto:[email protected]">[email protected]</a><br= > <a href=3D"http://www.blackmesatech.com" rel=3D"noreferrer" target=3D"_blan= k">http://www.blackmesatech.com</a><br> ******************************<wbr>**************<br> <br> </div></div></blockquote></div><br></div></div> --001a113e228a7633b4054eb9279a--