Re: TEI-L Digest - 3 May 2017 to 4 May 2017 (#2017-101)
MLH <[email protected]> Fri, 5 May 2017 09:11:06 +0000
| Newsgroups | gmane.text.tei.general |
|---|---|
| Message-ID | <DB5PR03MB1544AD8AB48C04BC8B93D332CDEB0@DB5PR03MB1544.eurprd03.prod.outlook.com> |
--_000_DB5PR03MB1544AD8AB48C04BC8B93D332CDEB0DB5PR03MB1544eurp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Dear Emmanuelle, My understanding is that the two numbers in @writtenLines (also @ruledLines= ), is that the first number gives the minimum number of lines per page or c= olumn in the codex as a whole, and the second gives the maximum number of l= ines per page or column in the codex as a whole. e.g. columns=3D"2" writtenLines=3D"20 30" would not mean that column a had 20 lines and column b 30 lines, but that t= he codex as a whole had 2 columns per page and between 20 and 30 lines per = column throughout. similarly columns=3D"1" writtenLines=3D"20 30" would mean a codex in long lines with between 20 and 30 lines per page thro= ughout. Best wishes, Matthew ________________________________ From: TEI (Text Encoding Initiative) public discussion list <TEI-L@LISTSERV= .BROWN.EDU> on behalf of TEI-L automatic digest system <[email protected]= ROWN.EDU> Sent: 05 May 2017 04:00 To: [email protected] Subject: TEI-L Digest - 3 May 2017 to 4 May 2017 (#2017-101) There are 10 messages totaling 2938 lines in this issue. Topics of the day: 1. "May contain: Empty element" 2. question about attribute @writtenLines (metadata) 3. @xml:base with @rendition (and maybe other pointers) (8) ---------------------------------------------------------------------- Date: Thu, 4 May 2017 11:28:58 +0100 From: Lou Burnard <[email protected]> Subject: Re: "May contain: Empty element" On 03/05/17 16:19, John P. McCaskey wrote: > When the spec for an element says =93May contain: Empty element=93 that > does not actually mean the spec=92d element can contain any other > element as long as the contained one is empty, right? It actually > means =93May contain: No other element,=93 right? > > Should that be changed? > > The "may contain" part is boiler plate text provided by the stylesheet in various languages: it might be tricky to change it. The other part is meant to imply that the element in question cannot contain anything, i.e. it is empty. Since there is now a proposal in the works (see https://github.com/TEIC/TEI/issues/1596) to allow for an empty content [https://avatars2.githubusercontent.com/u/4857689?v=3D3&s=3D400]<https://gi= thub.com/TEIC/TEI/issues/1596> Pure-ODD content model elements appear to be strictly weaker than regular l= anguages -- intended? =B7 Issue #1596 =B7 TEIC/TEI<https://github.com/TEIC/= TEI/issues/1596> github.com The elements used for content models in pure ODDs include, if I understand = chapter 22 correctly: Elements denoting atomic units of the content model (= anyElement, dataRef, elementRef, textNode, val... model to be represented in an ODD by using an explicit element called "<empty/>" that text maybe needs to be revisited. You might like to raise a Stylesheets ticket to remind someone to review it. ------------------------------ Date: Thu, 4 May 2017 12:45:53 +0200 From: Emmanuelle Morlock <[email protected]> Subject: question about attribute @writtenLines (metadata) Dear list, I was just wondering why the attribute @writtenLines on layout can contain = either one or two numbers (to represent the number of lines of one or two c= olumns), but not more. My question is mainly out of curiosity, I don=92t have any use case, but it= just seems slightly odd (the I may assume that in the manuscript world it= =92s very rare to have more than two columns=85) but what if ? How would yo= u do if you had more than two columns ? thanks ! Best, -- Emmanuelle Morlock IE CNRS - Humanit=E9s num=E9riques & TEI (Text Encoding Initiative) UMR 5189 HISoMA (Histoire et Sources des Mondes antiques) - Lyon http://www.hisoma.mom.fr/annuaire/morlock-emmanuelle MORLOCK Emmanuelle | Laboratoire HISOMA<http://www.hisoma.mom.fr/annuaire/m= orlock-emmanuelle> www.hisoma.mom.fr Activit=E9s principalesSoutien au projets de d'humanit=E9s num=E9riques et = d'=E9dition de sources anciennes en XML/TEI ;Conception et =E9laboration de= proc=E9dures de ... 06 85 84 69 16 @emma_morlock ------------------------------ Date: Thu, 4 May 2017 10:16:19 -0400 From: "John P. McCaskey" <[email protected]> Subject: Re: @xml:base with @rendition (and maybe other pointers) 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=92t seem to think there is anything to debate. I got one short answer and one dismissive comment about =94questions that simple.=94 Someone take a look and be sure I didn=92t 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 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] > <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]>> wrote: >>> >>> 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 =93dereferencing=94 of empty strings >>> and #fragments. But over here in XML-land, we don=92t do >>> =93dereferencing.=93 That=92s not a word we use here. Ignore th= at >>> 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=97it's assumed the client already has the document. >>>> >>>> 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=92t think xml:base had any necessary relation to the >>>> current document. I thought in XML (not HTML), it just sets >>>> a path for URIs below 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 @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> <div >>>>> xml:base=3D"http://www.dictionary.com/" >>>>> <http://www.dictionary.com/>> <p> <ref >>>>> target=3D"words/a.html#apple">apple</ref> </p> </div>-- >>>>> ------------------------------ Date: Thu, 4 May 2017 11:37:19 -0600 From: "C. M. Sperberg-McQueen" <[email protected]> Subject: Re: @xml:base with @rendition (and maybe other pointers) > On May 3, 2017, at 5:53 PM, John P. McCaskey <[email protected]> w= rote: > > So, bottom line: A standalone fragment identifier refers to the loaded do= cument 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? Yes and no. For some purposes, the ways in which the answer is 'no' are pedantic and can be ignored; for others they seem important. I did not respond to your summary yesterday, because objecting to the wording you used seemed unnecessarily pedantic. Also, I overlooked the second sentence, which I think is the wrong conclusion to draw. Given the following fragment of resource http://example.org/eg.xml <div xml:base=3D"http://www.dictionary.com/a.html"> <p> <ref target=3D"#apple">Apple</ref> <ref target=3D"a.html#avocado">Avocado</ref> <ref target=3D"http://www.dictionary.com/a.html#anise">Anise</ref> </p> </div> we can consider two ways of interpreting the target attributes. Note that the discussion below ignores some possibly salient facts: - URIs can denote different resources at different moments. (The discussion assumes the URI-resource mapping is not changing.) - A given resource can have multiple representations. (The discussion ignores any resulting complications.) - URIs whose path component ends in .xml and .html do not necessarily have particular MIME types, so there is no guarantee that a fragment identifier like #apple will have similar meanings. (The discussion assumes that fragment identifiers point to elements assigned IDs by the HTML 'id' attribute and/or the xml:id attribute.) Interpretation 1 ('xml:base values are irrelevant'). Ignore xml:base when resolving '#apple' [but not when resolving other relative references]. The target attributes are interpreted as denoting (a) http://example.org/eg.xml#apple (b) http://www.dictionary.com/a.html#avocado (c) http://www.dictionary.com/a.html#anise None of these have anything to do with any of: (d) http://www.dictionary.com/a.html#apple (e) http://example.org/eg.xml#avocado (f) http://example.org/eg.xml#anise Of these, (a) is a same-document reference and RFC 3986 says it "should" be dereferenced without a new retrieval action. If a new retrieval action is nevertheless launched, the resource retrieved is (a). [It is not clear to me whether the XVAI ('xml:base values are irrelevant') interpretation takes a position on whether any of these other than (a) are same-document references.] Interpretation 2 ('same-document references can be surprising', or SRCBS). Resolve all relative references against the base URI in the usual way. Dereference same-document references either by looking in the same document (as recommended by RFC 3986) or by launching a new retrieval operation. The target attributes are resolved to the absolute forms (d) http://www.dictionary.com/a.html#apple (b) http://www.dictionary.com/a.html#avocado (c) http://www.dictionary.com/a.html#anise All of these are same-document references, so according to RFC 3986, they should be dereferenced without a new retrieval action. If a retrieval action is nevertheless launched, it will go to URIs (d), (b), (c) respectively, not (a), (e), (f). From the fact that (d), (b), and (c) can be dereferenced without a new retrieval, it follows (as far as I can tell) that these three resources can also be denoted by URIs (a), (e), (f). The XVAI and SRCBS interpretations agree on the following proposition, which has important relevance for operations on the data: P1 The relative reference target=3D"#apple" can be dereferenced by locating the element in the current document with xml:id=3D"apple", if such an element exists. For people whose main interest is the truth or falsity of that proposition, then, the answer is "yes, that's right" -- the effect is the same, and all else is just pilpul. From P1, it follows (I think) that P2 The resource identified by target=3D"#apple" is identified by the absolute URI http://example.org/eg.xml#apple ((a) above). The two interpretations disagree, or seem to disagree, on a number of other propositions, most obviously: P3 The relative reference '#apple' does not identify the resource identifed by http://www.dictionary.com/a.html#apple. XVAI does not actually entail P2, but it is compatible with P3. (To reach P3 it is necessary to assume some rule like "No two URIs identify the same thing" or "If we don't know that a URI identifies a thing, then it does not identify that thing.") SRCBS entails the negation of P3. They also prescribe different URIs for the case that software determines to perform a fresh retrieval action for the relative reference #apple: XVAI prescribes the absolute URI (a), SRCBS prescribes URI (d). I don=92t believe anyone has seriously suggested XVAI as the relevant rule of interpretation for examples like the one given; what I have suggested (and I have understood Hugh Cayless to be agreeing with) is SRCBS. Operationally, they can have similar results in some circumstances (specifically: they can both result in no new retrieval action being undertaken in order to dereference =91#apple=92), but they differ in ways which can be critical. ******************************************** C. M. Sperberg-McQueen Black Mesa Technologies LLC [email protected] http://www.blackmesatech.com ******************************************** ------------------------------ Date: Thu, 4 May 2017 14:28:37 -0400 From: Hugh Cayless <[email protected]> Subject: Re: @xml:base with @rendition (and maybe other pointers) 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=97HTML 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] 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=92t seem to think there is anything to debate. I got on= e > short answer and one dismissive comment about =94questions that simple.= =94 > Someone take a look and be sure I didn=92t 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 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 =93dereferencing=94 of empty strings and #fragm= ents. >> But over here in XML-land, we don=92t do =93dereferencing.=93 That=92s n= ot 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=97it's assumed the client already has 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=92t think xml:base had any necessary relation to the current >>> 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> >>>> -- >>>> >>>> ------------------------------ Date: Thu, 4 May 2017 15:31:42 -0400 From: "John P. McCaskey" <[email protected]> Subject: Re: @xml:base with @rendition (and maybe other pointers) What is the short bottom-line guidance for someone trying to encode a 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=92t try to point outside your TEI document by using xml:base 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=92s unambiguous, has practical benefits, requires no knowledge of RFCs or 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 > 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=97HTML 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] > > 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#stillBugsInTheImplementationOfH= tmlHyperlinks > 2. http://w3future.com/weblog/2005/08/14.xml#howToUseBaseUris > > On Thu, May 4, 2017 at 10:16 AM, John P. McCaskey > <[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=92t seem to think there is anything to debate. I > got one short answer and one dismissive comment about =94questions > that simple.=94 Someone take a look and be sure I didn=92t 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 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] <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]>> wrote= : >>>> >>>> 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 =93dereferencing=94 of empty >>>> strings and #fragments. But over here in XML-land, we >>>> don=92t do =93dereferencing.=93 That=92s 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=97it's assumed the client already has the document. >>>>> >>>>> 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=92t think xml:base had any necessary relation to >>>>> the current document. I thought in XML (not HTML), it >>>>> just sets a path for URIs below 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 @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> <div >>>>>> xml:base=3D"http://www.dictionary.com/" >>>>>> <http://www.dictionary.com/>> <p> <ref >>>>>> target=3D"words/a.html#apple">apple</ref> </p> >>>>>> </div>-- >>>>>> ------------------------------ Date: Thu, 4 May 2017 14:32:37 -0600 From: "C. M. Sperberg-McQueen" <[email protected]> Subject: Re: @xml:base with @rendition (and maybe other pointers) > On May 4, 2017, at 12:28 PM, Hugh Cayless <[email protected]> wrote: > > That's a rather favorable interpretation on your part. One person agrees = with you without elucidating, I=92m not sure this is true. What Eliot Kimber said is that in the context= given, =91#apple=92 identifies the same thing as =91http://www.dictionary.= com/a.html#apple'. Does that distinguish between the two (? are there just= two?) =97 does that distinguish among the various interpretations of the s= ituation offered so far? I don=92t think so. I think the disagreement we have is not over the state= ment affirmed by Eliot Kimber, but over the following two claims: C1 In the context described, =91#apple=92 is a same-document reference an= d can therefore by definition be dereferenced without a new retrieval actio= n. C2 In the context described, =91#apple=92 does not refer to the element i= n the current document with xml:id=3D=93apple=94 (if any); it cannot be derefe= renced without a new retrieval action. I intend C1 as a representation of the interpretation of 3986 I=92ve been o= ffering, and C2 as a representation of the interpretation offered by John M= cCaskey. (SRCBS and XVAI, in my note of earlier today. > one says this discussion has jumped the shark (which is fair), and the th= ird (Michael Kay) gives a fuller answer which adds up to "it depends". Mich= ael 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 URI is *always* computed with reference to its base. Optimizations which produce the same result are, of course, allowed. The p= receding paragraph is a claim about the meaning of certain language constru= cts, not a claim about what the CPU and network controller do during evalua= tion 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 =93defined to be within=94 the current document; in co= nsequence no new retrieval is necessary and a new retrieval should be avoid= ed. The 'should' here means that 3986 recommends that new retrievals be av= oided, but does not forbid new retrievals; if conforming processors or spec= s have good reason for launching new retrievals, that's not a violation 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 b= y the XSLT spec that the relevant resource is not within the current docume= nt.) > > The thing is, I'm not aware of any TEI attributes or element/attribute co= mbinations 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 s= ame-document references *mean* in the context of TEI documents with @xml:ba= se. 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 a= lso think that we'd be better off adhering to the letter of RFC 3986. The u= se of same-document references in TEI documents is ubiquitous, and I'm firm= ly against anything that might break them. Is it clear what counts as breakage, here? 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? 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=92= s 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 documents= and not breaking them, but between breaking those belonging to one project= and breaking those belonging to another project. > For what it's worth, modern web browsers seem to agree with your interpre= tation (mutatis mutandis=97HTML base is not @xml:base). As far as I can tel= l, 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.co= m/doc.html containing <base href=3D=93http://example.org/base.html=94>, a l= ink of the form <a href=3D=93#quovadis=94>where does this connect to?</a> w= ill go to =85 where? I think the two obvious things one might expect to see in the address bar a= fter 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 with= out a refresh (just scrolling to the place). If a browser shows one of these addresses, does that constitute a claim tha= t the other identifies a different resource? Or does it only constitute a = decision on the part of the browser about which of the two possible paths t= o a given resource it should take? > 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] Thank you for that reference. I think the rules in 3986 make perfect sense if one assumes Roy Fielding=92= s 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 whi= ch would otherwise be long is not a scenario worth bending over backwards f= or. (That is, it seems to me to simplify matters, rather than complicating= them.) If one doesn=92t want to make that assumption, some relatively simple rules= like the following might go some distance towards reducing the likelihood = of unpleasant surprises: - Use the form =93#fragment=94 only for references to locations in the cu= rrent document. These will always be same-document references within the m= eaning of RFC 3986. - Use xml:base to set all but the last bit of the URI, but not to set a f= ull document URI: xml:base=3D=93http://dictionary.example.org/entries/=93 = with relative references to =93a.html#apple=94 and =93a.html#anodyne=94 wil= l be better than xml:base=3D=93http://dictionary.example.org/entries/a.html= =94 with relative referencs to =93#apple=94 and =93#anodyne=94. These will= never be taken to be same-document references. Note, however, that while =93#fragment=94 will always be a same-document re= ference, it will ALSO always be a reference to the given fragment in the re= source identified by the base URI. If that=92s not logically the same as t= he resource within which the reference occurs, you=92re playing with fire: = RFC 3986 says =93#fragment=94 =93should=94 be dereferenced without a new r= etrieval, not that it must be. Any software will be perfectly within its r= ights to retrieve the base URI and look for the fragment there. > > References: > 1. http://w3future.com/weblog/2005/01/13.xml#stillBugsInTheImplementation= OfHtmlHyperlinks > 2. http://w3future.com/weblog/2005/08/14.xml#howToUseBaseUris ******************************************** C. M. Sperberg-McQueen Black Mesa Technologies LLC [email protected] http://www.blackmesatech.com ******************************************** ------------------------------ Date: Thu, 4 May 2017 14:42:11 -0600 From: "C. M. Sperberg-McQueen" <[email protected]> Subject: Re: @xml:base with @rendition (and maybe other pointers) > On May 4, 2017, at 1:31 PM, John P. McCaskey <[email protected]> w= rote: > > What is the short bottom-line guidance for someone trying to encode a doc= ument? Is it this? > > To point inside a TEI document, as for @rendition, use pointers of the fo= rm #destination. Any later changes to xml:base values will not mess up your= internal # pointers. > > Don=92t try to point outside your TEI document by using xml:base plus a #= destination in the pointer attribute. No xml:base attribute will be prepend= ed to a pointer that begins with a #. No. Sorry. That=92s not the way it works, and I think this discussion ha= s already demonstrated that it=92s a dangerous way to describe the behavior= . If you want to keep things simple for the encoders, I=92d rephrase this as = something like: Don=92t try to point outside your TEI document by using xm= l:base plus a #destination in the pointer attribute. It does not have the = desired meaning. Point outside your TEI document either using an absolute = URI or an xml:base attribute plus the final part of the path (the =91file n= ame=92 part) and the fragment identifier. So NOT <ptr xml:base=3D=93lib/fo= o.xml=94 target=3D=93#bar=94/> but <ptr xml:base=3D=93lib/=94 target=3D=93f= oo.xml#bar=94/>. ******************************************** C. M. Sperberg-McQueen Black Mesa Technologies LLC [email protected] http://www.blackmesatech.com ******************************************** ------------------------------ Date: Thu, 4 May 2017 20:44:29 +0000 From: Martin Mueller <[email protected]> Subject: Re: @xml:base with @rendition (and maybe other pointers) I=92m following this thread from a distance (much of it is way over my head= ), but it reminds me of something I=92ve said before. Every few months or s= o there is an extended discussion on the TEI list that raises a tough issue= . It would be helpful to the members at large if the Council assumed the r= esponsibility for digesting such a discussion into a one or two-page summar= y. There might a special place on the site for such papers. Sometimes thes= e discussion reach agreement, sometimes they just help clarify positions. The obvious objection to my suggestion is that the members of the Council h= ave other and more pressing things to do. On the other hand, documentation = is clearly a responsibility of the Council, and position papers of this typ= e are a kind of documentation. Or one could say =93Why don=92t the readers = of the list take or make the time to read the extended discussion?=94 A goo= d question, but there is a very high time cost involved in tracking a discu= ssion that has half a dozen participants and dozens of entries. I can=92t be the only follower of this list who wouldn=92t be grateful for = a succinct account of =93what was all this about?=94 On 5/4/17, 3:32 PM, "TEI (Text Encoding Initiative) public discussion list = on behalf of C. M. Sperberg-McQueen" <[email protected] on behalf of= [email protected]> wrote: > On May 4, 2017, at 12:28 PM, Hugh Cayless <[email protected]> wro= te: > > That's a rather favorable interpretation on your part. One person agr= ees with you without elucidating, I=92m not sure this is true. What Eliot Kimber said is that in the con= text given, =91#apple=92 identifies the same thing as =91https://urldefense= .proofpoint.com/v2/url?u=3Dhttp-3A__www.dictionary.com_a.html-23apple&d=3DD= wIFaQ&c=3DyHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=3DrG8zxOdssqSzDRz4x= 1GLlmLOW60xyVXydxwnJZpkxbk&m=3DbLi7T2xrOg4vVFRr7hE1SVQa7jmldPgLzCrevoRJWI4&= s=3DOlhWZ8ch2cUtq8qgCtAvoznqSamkaD9OBrjp2Js-eJs&e=3D '. Does that distingu= ish between the two (? are there just two?) =97 does that distinguish among= the various interpretations of the situation offered so far? I don=92t think so. I think the disagreement we have is not over the s= tatement affirmed by Eliot Kimber, but over the following two claims: C1 In the context described, =91#apple=92 is a same-document referenc= e and can therefore by definition be dereferenced without a new retrieval a= ction. C2 In the context described, =91#apple=92 does not refer to the eleme= nt in the current document with xml:id=3D=93apple=94 (if any); it cannot be de= referenced without a new retrieval action. I intend C1 as a representation of the interpretation of 3986 I=92ve be= en offering, and C2 as a representation of the interpretation offered by Jo= hn McCaskey. (SRCBS and XVAI, in my note of earlier today. > one says this discussion has jumped the shark (which is fair), and th= e 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 URI is *always* computed with reference to its base. Optimizations which produce the same result are, of course, allowed. T= he preceding paragraph is a claim about the meaning of certain language con= structs, not a claim about what the CPU and network controller do during ev= aluation of an expression by a conforming processor. If it is then determined to be a same-document URI, the resource identi= fied by that URI is then =93defined to be within=94 the current document; i= n consequence no new retrieval is necessary and a new retrieval should be a= voided. The 'should' here means that 3986 recommends that new retrievals b= e avoided, but does not forbid new retrievals; if conforming processors or = specs have good reason for launching new retrievals, that's not a violation= of the rules of 3986. The XSLT spec defines the document() function as al= ways launching a new retrieval. (Note that this does not amount to any cla= im by the XSLT spec that the relevant resource is not within the current do= cument.) > > The thing is, I'm not aware of any TEI attributes or element/attribut= e combinations which are defined as *forcing* a retrieval action. I'd be ha= ppy 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 wh= at same-document references *mean* in the context of TEI documents with @xm= l: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. T= he 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? If a given interpretation of the URI specs causes some URI references t= o break (by which I mean: to have an interpretation different from what the= encoders intended), can we be confident that a contrary interpretation wil= l 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, i= t=92s seldom the case that everyone interprets it the same way. There is s= ome risk that your choice does not lie between breaking things in TEI docum= ents and not breaking them, but between breaking those belonging to one pro= ject and breaking those belonging to another project. > For what it's worth, modern web browsers seem to agree with your inte= rpretation (mutatis mutandis=97HTML base is not @xml:base). As far as I can= tell, probably because of a desire on the part of the Mozilla developers b= ack 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 https://urlde= fense.proofpoint.com/v2/url?u=3Dhttp-3A__example.com_doc.html&d=3DDwIFaQ&c= =3DyHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=3DrG8zxOdssqSzDRz4x1GLlmLO= W60xyVXydxwnJZpkxbk&m=3DbLi7T2xrOg4vVFRr7hE1SVQa7jmldPgLzCrevoRJWI4&s=3D29y= 8v-TK44tIIjTyqctxB4Lf9WPymQrVdzrLIvEW6qI&e=3D containing <base href=3D=93h= ttps://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__example.org_base.html-= 25EF-25BF-25BD&d=3DDwIFaQ&c=3DyHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r= =3DrG8zxOdssqSzDRz4x1GLlmLOW60xyVXydxwnJZpkxbk&m=3DbLi7T2xrOg4vVFRr7hE1SVQa= 7jmldPgLzCrevoRJWI4&s=3DlknBDjsTtVRI870bNMIn9dPdWUvd3whJSBhji92091Q&e=3D ??= >, a link of the form <a href=3D=93#quovadis=94>where does this connect to?= </a> will go to =85 where? I think the two obvious things one might expect to see in the address b= ar after traversing that link are https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__example.com_d= oc.html-23quovadis&d=3DDwIFaQ&c=3DyHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6= ws&r=3DrG8zxOdssqSzDRz4x1GLlmLOW60xyVXydxwnJZpkxbk&m=3DbLi7T2xrOg4vVFRr7hE1= SVQa7jmldPgLzCrevoRJWI4&s=3D1hCsliHZFQuB2OctN_76mPFbm9rUqdBn1A2SVJccTFc&e= =3D https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__example.org_b= ase.html-23quovaids&d=3DDwIFaQ&c=3DyHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA= 6ws&r=3DrG8zxOdssqSzDRz4x1GLlmLOW60xyVXydxwnJZpkxbk&m=3DbLi7T2xrOg4vVFRr7hE= 1SVQa7jmldPgLzCrevoRJWI4&s=3DCOMDCJ41VanHpbGX9WMOSGuIRx38Szt4ldxlhdtB8vs&e= =3D 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 constitut= e a decision on the part of the browser about which of the two possible pat= hs to a given resource it should take? > 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 shorth= and references rather than to set a canonical URI for the current document,= is abusive.[2] Thank you for that reference. I think the rules in 3986 make perfect sense if one assumes Roy Fieldin= g=92s principle that the base URI within a document should be the base URI = of the document, and that using xml:base or html:base to shorten references= which would otherwise be long is not a scenario worth bending over backwar= ds for. (That is, it seems to me to simplify matters, rather than complica= ting them.) If one doesn=92t want to make that assumption, some relatively simple r= ules like the following might go some distance towards reducing the likelih= ood of unpleasant surprises: - Use the form =93#fragment=94 only for references to locations in th= e 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=93https://urldefense.proofpoint.com/v2/u= rl?u=3Dhttp-3A__dictionary.example.org_entries_&d=3DDwIFaQ&c=3DyHlS04HhBrae= s5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=3DrG8zxOdssqSzDRz4x1GLlmLOW60xyVXydxwnJZp= kxbk&m=3DbLi7T2xrOg4vVFRr7hE1SVQa7jmldPgLzCrevoRJWI4&s=3DuiFZhf2CmFnQIHzkLr= sBKwvBnPTf2AtYINKYtwKyWMI&e=3D =93 with relative references to =93a.html#ap= ple=94 and =93a.html#anodyne=94 will be better than xml:base=3D=93https://u= rldefense.proofpoint.com/v2/url?u=3Dhttp-3A__dictionary.example.org_entries= _a.html&d=3DDwIFaQ&c=3DyHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=3DrG8z= xOdssqSzDRz4x1GLlmLOW60xyVXydxwnJZpkxbk&m=3DbLi7T2xrOg4vVFRr7hE1SVQa7jmldPg= LzCrevoRJWI4&s=3DpNUfEVwlyFPDAjVMWdE4ChwxmVlqytmyd6fi54Odw5A&e=3D =94 with = relative referencs to =93#apple=94 and =93#anodyne=94. These will never be= taken to be same-document references. Note, however, that while =93#fragment=94 will always be a same-documen= t reference, it will ALSO always be a reference to the given fragment in th= e resource identified by the base URI. If that=92s not logically the same = as the resource within which the reference occurs, you=92re playing with fi= re: RFC 3986 says =93#fragment=94 =93should=94 be dereferenced without a n= ew retrieval, not that it must be. Any software will be perfectly within i= ts rights to retrieve the base URI and look for the fragment there. > > References: > 1. https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__w3future.com= _weblog_2005_01_13.xml-23stillBugsInTheImplementationOfHtmlHyperlinks&d=3DD= wIFaQ&c=3DyHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=3DrG8zxOdssqSzDRz4x= 1GLlmLOW60xyVXydxwnJZpkxbk&m=3DbLi7T2xrOg4vVFRr7hE1SVQa7jmldPgLzCrevoRJWI4&= s=3DEOYAXmorJnWNneuoby45ZricHwP8Ll9_ub7gKR2Ck-4&e=3D > 2. https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__w3future.com= _weblog_2005_08_14.xml-23howToUseBaseUris&d=3DDwIFaQ&c=3DyHlS04HhBraes5BQ9u= eu5zKhE7rtNXt_d012z2PA6ws&r=3DrG8zxOdssqSzDRz4x1GLlmLOW60xyVXydxwnJZpkxbk&m= =3DbLi7T2xrOg4vVFRr7hE1SVQa7jmldPgLzCrevoRJWI4&s=3DpUcTcRc_mAHAy8r8nPCz8cD8= nuQBDOqDvJ-37BCwJJQ&e=3D ******************************************** C. M. Sperberg-McQueen Black Mesa Technologies LLC [email protected] https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__www.blackmesatech= .com&d=3DDwIFaQ&c=3DyHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=3DrG8zxOd= ssqSzDRz4x1GLlmLOW60xyVXydxwnJZpkxbk&m=3DbLi7T2xrOg4vVFRr7hE1SVQa7jmldPgLzC= revoRJWI4&s=3DceMDgmbvrnWoyJVZ8VidJIp4udgcdq0tzNL8qVw_itM&e=3D ******************************************** ------------------------------ Date: Thu, 4 May 2017 17:07:00 -0400 From: Hugh Cayless <[email protected]> Subject: Re: @xml:base with @rendition (and maybe other pointers) 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 =93defined to be within=94 the current doc= ument; > 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= =92s > 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=97HTML 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=93 > http://example.org/base.html=94>, a link of the form <a > href=3D=93#quovadis=94>where does this connect to?</a> will go to =85 whe= re? > 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= =92s > 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=92t want to make that assumption, some relatively simple rul= es > like the following might go some distance towards reducing the likelihood > of unpleasant surprises: > > - Use the form =93#fragment=94 only for references to locations 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=93http://dictionary.example.org/entries/= =93 > with relative references to =93a.html#apple=94 and =93a.html#anodyne=94 w= ill be > better than xml:base=3D=93http://dictionary.example.org/entries/a.html=94= with > relative referencs to =93#apple=94 and =93#anodyne=94. These will never = be taken > to be same-document references. > > Note, however, that while =93#fragment=94 will always be a same-document > reference, it will ALSO always be a reference to the given fragment in th= e > resource identified by the base URI. If that=92s not logically the same = as > the resource within which the reference occurs, you=92re playing with fir= e: > RFC 3986 says =93#fragment=94 =93should=94 be dereferenced 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 > ******************************************** > > ------------------------------ End of TEI-L Digest - 3 May 2017 to 4 May 2017 (#2017-101) ********************************************************** --_000_DB5PR03MB1544AD8AB48C04BC8B93D332CDEB0DB5PR03MB1544eurp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1= 252"> <style type=3D"text/css" style=3D"display:none;"><!-- P {margin-top:0;margi= n-bottom:0;} --></style> </head> <body dir=3D"ltr"> <div id=3D"divtagdefaultwrapper" style=3D"font-size:12pt;color:#000000;font= -family:Calibri,Arial,Helvetica,sans-serif;" dir=3D"ltr"> <p>Dear Emmanuelle, <br> </p> <p>My understanding is that the two numbers in @writtenLines (also @ru= ledLines), is that the first number gives the minimum number of lines per p= age or column in the codex as a whole, and the second gives the maximum num= ber of lines per page or column in the codex as a whole. <br> </p> <p>e.g. <br> </p> <p>columns=3D"2" writtenLines=3D"20 30" <br> </p> <p>would not mean that column a had 20 lines and column b 30 lines, but tha= t the codex as a whole had 2 columns per page and between 20 and 30 lines p= er column throughout.</p> <p>similarly</p> <p><span>columns=3D"1" writtenLines=3D"20 30" </span><b= r> </p> <p>would mean a codex in long lines with between 20 and 30 lines per page t= hroughout.</p> <p>Best wishes,</p> <p>Matthew<br> </p> <br> <br> <div style=3D"color: rgb(0, 0, 0);"> <div> <hr tabindex=3D"-1" style=3D"display:inline-block; width:98%"> <div id=3D"x_divRplyFwdMsg" dir=3D"ltr"><font style=3D"font-size:11pt" colo= r=3D"#000000" face=3D"Calibri, sans-serif"><b>From:</b> TEI (Text Encoding = Initiative) public discussion list <[email protected]> on beha= lf of TEI-L automatic digest system <[email protected]><br> <b>Sent:</b> 05 May 2017 04:00<br> <b>To:</b> [email protected]<br> <b>Subject:</b> TEI-L Digest - 3 May 2017 to 4 May 2017 (#2017-101)</font> <div> </div> </div> </div> <font size=3D"2"><span style=3D"font-size:10pt;"> <div class=3D"PlainText">There are 10 messages totaling 2938 lines in this = issue.<br> <br> Topics of the day:<br> <br> 1. "May contain: Empty element"<br> 2. question about attribute @writtenLines (metadata)<br> 3. @xml:base with @rendition (and maybe other pointers) (8)<br> <br> ----------------------------------------------------------------------<br> <br> Date: Thu, 4 May 2017 11:28:58 +0100<br> From: Lou Burnard <[email protected]><br= > Subject: Re: "May contain: Empty element"<br> <br> On 03/05/17 16:19, John P. McCaskey wrote:<br> > When the spec for an element says =93May contain: Empty element=93 tha= t <br> > does not actually mean the spec=92d element can contain any other <br> > element as long as the contained one is empty, right? It actually <br> > means =93May contain: No other element,=93 right?<br> ><br> > Should that be changed?<br> ><br> ><br> <br> The "may contain" part is boiler plate text provided by the style= sheet <br> in various languages: it might be tricky to change it. The other part is <b= r> meant to imply that the element in question cannot contain anything, <br> i.e. it is empty. Since there is now a proposal in the works (see <br> <a href=3D"https://github.com/TEIC/TEI/issues/1596" id=3D"LPlnk561822" prev= iewremoved=3D"true">https://github.com/TEIC/TEI/issues/1596</a>) to a= llow for an empty content <div id=3D"LPBorder_GT_14939752427340.8912108702195994" style=3D"margin-bot= tom: 20px; overflow: auto; width: 100%; text-indent: 0px;"> <table id=3D"LPContainer_14939752427290.7457787929213734" style=3D"width: 9= 0%; background-color: rgb(255, 255, 255); position: relative; overflow: aut= o; padding-top: 20px; padding-bottom: 20px; margin-top: 20px; border-top: 1= px dotted rgb(200, 200, 200); border-bottom: 1px dotted rgb(200, 200, 200);= " role=3D"presentation" cellspacing=3D"0"> <tbody> <tr style=3D"border-spacing: 0px;" valign=3D"top"> <td id=3D"ImageCell_14939752427300.11624356572982253" style=3D"width: 250px= ; position: relative; display: table-cell; padding-right: 20px;" colspan=3D= "1"> <div id=3D"LPImageContainer_14939752427300.333276741717902" style=3D"backgr= ound-color: rgb(255, 255, 255); height: 250px; position: relative; margin: = auto; display: table; width: 250px;"> <a id=3D"LPImageAnchor_14939752427310.4235254913032114" style=3D"display: t= able-cell; text-align: center;" href=3D"https://github.com/TEIC/TEI/issues/= 1596" target=3D"_blank"><img style=3D"display: inline-block; max-width: 250= px; max-height: 250px; height: 250px; width: 250px; border-width: 0px; vert= ical-align: bottom;" id=3D"LPThumbnailImageID_14939752427310.02716147774953= 8365" width=3D"250" height=3D"250" src=3D"https://avatars2.githubuserconten= t.com/u/4857689?v=3D3&s=3D400"></a></div> </td> <td id=3D"TextCell_14939752427320.9678641718239404" style=3D"vertical-align= : top; position: relative; padding: 0px; display: table-cell;" colspan=3D"2= "> <div id=3D"LPRemovePreviewContainer_14939752427320.9486097071502633"></div> <div id=3D"LPTitle_14939752427320.10952548567936904" style=3D"top: 0px; col= or: rgb(0, 120, 215); font-weight: 400; font-size: 21px; font-family: "= ;wf_segoe-ui_light","Segoe UI Light","Segoe WP Light&qu= ot;,"Segoe UI","Segoe WP",Tahoma,Arial,sans-serif; line= -height: 21px;"> <a id=3D"LPUrlAnchor_14939752427320.13335782404330554" style=3D"text-decora= tion: none;" href=3D"https://github.com/TEIC/TEI/issues/1596" target=3D"_bl= ank">Pure-ODD content model elements appear to be strictly weaker than regu= lar languages -- intended? =B7 Issue #1596 =B7 TEIC/TEI</a></div> <div id=3D"LPMetadata_14939752427330.4057287606307245" style=3D"margin: 10p= x 0px 16px; color: rgb(102, 102, 102); font-weight: 400; font-family: "= ;wf_segoe-ui_normal","Segoe UI","Segoe WP",Tahoma,= Arial,sans-serif; font-size: 14px; line-height: 14px;"> github.com</div> <div id=3D"LPDescription_14939752427330.8268234060783209" style=3D"display:= block; color: rgb(102, 102, 102); font-weight: 400; font-family: "wf_= segoe-ui_normal","Segoe UI","Segoe WP",Tahoma,Aria= l,sans-serif; font-size: 14px; line-height: 20px; max-height: 100px; overfl= ow: hidden;"> The elements used for content models in pure ODDs include, if I understand = chapter 22 correctly: Elements denoting atomic units of the content model (= anyElement, dataRef, elementRef, textNode, val...</div> </td> </tr> </tbody> </table> </div> <br> model to be represented in an ODD by using an explicit element called <br> "<empty/>" that text maybe needs to be revisite= d. You might like to <br> raise a Stylesheets ticket to remind someone to review it.<br> <br> <br> ------------------------------<br> <br> Date: Thu, 4 May 2017 12:45:53 +0200<br> From: Emmanuelle Morlock <[email protected]>= ;<br> Subject: question about attribute @writtenLines (metadata)<br> <br> Dear list,<br> <br> I was just wondering why the attribute @writtenLines on layout can con= tain either one or two numbers (to represent the number of lines of one or = two columns), but not more.<br> <br> My question is mainly out of curiosity, I don=92t have any use case, but it= just seems slightly odd (the I may assume that in the manuscript world it= =92s very rare to have more than two columns=85) but what if ? How would yo= u do if you had more than two columns ? <br> <br> thanks !<br> Best, <br> -- <br> Emmanuelle Morlock<br> IE CNRS - Humanit=E9s num=E9riques & TEI (Text Encoding Initiative)<br> UMR 5189 HISoMA (Histoire et Sources des Mondes antiques) - Lyon<br> <a href=3D"http://www.hisoma.mom.fr/annuaire/morlock-emmanuelle" id=3D"LPln= k779897" previewremoved=3D"true">http://www.hisoma.mom.fr/annuaire/morlock-= emmanuelle</a> <div id=3D"LPBorder_GT_14939752994260.8257561761230685" style=3D"margin-bot= tom: 20px; overflow: auto; width: 100%; text-indent: 0px;"> <table id=3D"LPContainer_14939752994200.31993924872024293" style=3D"width: = 90%; background-color: rgb(255, 255, 255); position: relative; overflow: au= to; padding-top: 20px; padding-bottom: 20px; margin-top: 20px; border-top: = 1px dotted rgb(200, 200, 200); border-bottom: 1px dotted rgb(200, 200, 200)= ;" role=3D"presentation" cellspacing=3D"0"> <tbody> <tr style=3D"border-spacing: 0px;" valign=3D"top"> <td id=3D"TextCell_14939752994220.07261932311049946" style=3D"vertical-alig= n: top; position: relative; padding: 0px; display: table-cell;" colspan=3D"= 2"> <div id=3D"LPRemovePreviewContainer_14939752994230.9296336326709831"></div> <div id=3D"LPTitle_14939752994230.8155300743021431" style=3D"top: 0px; colo= r: rgb(0, 120, 215); font-weight: 400; font-size: 21px; font-family: "= wf_segoe-ui_light","Segoe UI Light","Segoe WP Light&quo= t;,"Segoe UI","Segoe WP",Tahoma,Arial,sans-serif; line-= height: 21px;"> <a id=3D"LPUrlAnchor_14939752994240.0042646812302495896" style=3D"text-deco= ration: none;" href=3D"http://www.hisoma.mom.fr/annuaire/morlock-emmanuelle= " target=3D"_blank">MORLOCK Emmanuelle | Laboratoire HISOMA</a></div> <div id=3D"LPMetadata_14939752994240.29887269272311834" style=3D"margin: 10= px 0px 16px; color: rgb(102, 102, 102); font-weight: 400; font-family: &quo= t;wf_segoe-ui_normal","Segoe UI","Segoe WP",Tahoma= ,Arial,sans-serif; font-size: 14px; line-height: 14px;"> www.hisoma.mom.fr</div> <div id=3D"LPDescription_14939752994250.022526769284129444" style=3D"displa= y: block; color: rgb(102, 102, 102); font-weight: 400; font-family: "w= f_segoe-ui_normal","Segoe UI","Segoe WP",Tahoma,Ar= ial,sans-serif; font-size: 14px; line-height: 20px; max-height: 100px; over= flow: hidden;"> Activit=E9s principalesSoutien au projets de d'humanit=E9s num=E9riques et = d'=E9dition de sources anciennes en XML/TEI ;Conception et =E9laboration de= proc=E9dures de ...</div> </td> </tr> </tbody> </table> </div> <br> 06 85 84 69 16<br> @emma_morlock<br> <br> ------------------------------<br> <br> Date: Thu, 4 May 2017 10:16:19 -0400<br> From: "John P. McCaskey" <mailbox@JOHNMCCASK= EY.COM><br> Subject: Re: @xml:base with @rendition (and maybe other pointers)<br> <br> I asked about this over at XML-DEV, <br> <a href=3D"http://lists.xml.org/archives/xml-dev/201705/msg00008.html" id= =3D"LPlnk403392" previewremoved=3D"true">http://lists.xml.org/archives/xml-= dev/201705/msg00008.html</a>.<br> <br> Opinion there is with me and opposite the majority here.<br> <br> Readers there don=92t seem to think there is anything to debate. I got one = <br> short answer and one dismissive comment about =94questions that simple.=94 = <br> Someone take a look and be sure I didn=92t word my question unfairly.<br> <br> Whichever interpretation TEI adopts, sounds like it should be documented <b= r> in the Guidelines or a note somewhere.<br> <br> If the McCaskey/XML-DEV interpretation is adopted, the GitHub issue I <br> posted about @rendition stands. If not, that issue goes away.<br> <br> John<br> <br> <br> <br> On 5/3/2017 8:03 PM, Hugh Cayless wrote:<br> > Those are the cards we've been dealt, yeah.<br> ><br> > Sent from my phone.<br> ><br> > On May 3, 2017, at 19:53, John P. McCaskey <[email protected]= M <br> > <<a href=3D"mailto:[email protected]">mailto:mailbox@JOHNMCC= ASKEY.COM</a>>> wrote:<br> ><br> >> So, bottom line: A standalone fragment identifier refers to the <b= r> >> loaded document and all the xml:base values above it in the hierar= chy <br> >> are irrelevant. Encoders cannot use xml:base to direct a standalon= e <br> >> #fragment value to a location outside the loaded document.<br> >><br> >> Is that right?<br> >><br> >> --<br> >><br> >><br> >> On 5/3/2017 6:20 PM, Hugh Cayless wrote:<br> >>> No. This clarifies the expected behavior when (e.g.) you have = <br> >>> @xml:base=3D"#frag". It says nothing whatever about = <p <br> >>> rendition=3D"#foo">. I don't think these specific= ations interact in <br> >>> the way you're positing. Quite the opposite.<br> >>><br> >>> On Wed, May 3, 2017 at 6:13 PM, John P. McCaskey <br> >>> <[email protected] <<a href=3D"mailto:mailbox@joh= nmccaskey.com">mailto:[email protected]</a>>> wrote:<br> >>><br> >>> The special behavior of same-document = references in RFC 3986 is<br> >>> disavowed by W3C:<br> >>><br> >>> 4.4 Interpreta= tion of same-document references<br> >>><br> >>> RFC 3986 defin= es certain relative URI references, in<br> >>> particular the= empty string and those of the form #fragment,<br> >>> as same-docume= nt references. Dereferencing of same-document<br> >>> references is = handled specially. However, their use as the<br> >>> value of an *x= ml:base attribute does not* *involve<br> >>> *dereferencing= , and XML Base processors should resolve them<br> >>> in the usual w= ay. In particular, xml:base=3D"" does not reset<br> >>> the base URI t= o that of the containing document.<br> >>><br> >>> Note:<br> >>><br> >>> Some existing = processors do treat these xml:base values as<br> >>> resetting the = base URI to that of the containing document,<br> >>> so the use of = such values is strongly discouraged.<br> >>><br> >>> This says:<br> >>><br> >>> RFC 3986 defin= es special =93dereferencing=94 of empty strings<br> >>> and #fragments= . But over here in XML-land, we don=92t do<br> >>> =93dereferenci= ng.=93 That=92s not a word we use here. Ignore that<br> >>> stuff about sa= me-document references. Just resolve empty<br> >>> strings and #f= ragments as specified in the W3C<br> >>> Recommendation= above. And those of you who did carry that<br> >>> stuff over fro= m 3986 to XML-land, shame on you. You messed<br> >>> things up for = the rest of us.<br> >>><br> >>><br> >>> A note has:<br> >>><br> >>> 5. The meaning= s of xml:base=3D"" and xml:base=3D"#frag" have<br> >>> been clarified= ;<br> >>><br> >>> This says:<br> >>><br> >>> In this second= version of this recommendation, we added<br> >>> paragraph 4.4 = specifically to get you 3986 people to stop<br> >>> polluting our = W3C with your special cases. Stop doing that.<br> >>><br> >>> No?<br> >>><br> >>> -- John<br> >>><br> >>><br> >>><br> >>><br> >>><br> >>><br> >>> On 5/3/2017 5:09 PM, Hugh Cayless wrot= e:<br> >>>> That's exactly what it does. It's = just that the behavior of<br> >>>> same-document references is prescr= ibed in such a way that they<br> >>>> end up resolving to the current do= cument regardless of the<br> >>>> value of the @xml:base.<br> >>>><br> >>>> Put another way, @xml:base has an = influence on what the client<br> >>>> application will retrieve when it = dereferences a URI and<br> >>>> retrieves the referenced document,= but in the case of<br> >>>> same-document references no such r= etrieval is expected to<br> >>>> occur=97it's assumed the client al= ready has the document.<br> >>>><br> >>>> On Wed, May 3, 2017 at 4:29 PM, Jo= hn P. McCaskey<br> >>>> <[email protected] <<= a href=3D"mailto:[email protected]">mailto:[email protected]<= /a>>> wrote:<br> >>>><br> >>>> Oh. I thou= ght it obvious they all resolved the same.<br> >>>><br> >>>> I think th= e same about this one. You think otherwise?<br> >>>><br> >>>> <div xm= l:base=3D"<a href=3D"http://www.myteiproject.com/">http://www.myteipro= ject.com/</a>"<br> >>>> <<a hre= f=3D"http://www.myteiproject.com/">http://www.myteiproject.com/</a>> <= ;div xml:base=3D"images/"><br> >>>> <div>= ; <graphic url=3D"logo.jpg"> </div> <div<br> >>>> xml:base= =3D"<a href=3D""></a>http://www.dictionary.com/words/<br> >>>> <<a hre= f=3D"http://dictionary.com/words/">http://dictionary.com/words/</a>>&quo= t;> <p xml:base=3D"a.html"> <ref<br> >>>> target=3D&= quot;#apple">apple</ref> </p> </div> </div>= </div><br> >>>><br> >>>> I didn=92t= think xml:base had any necessary relation to the<br> >>>> current do= cument. I thought in XML (not HTML), it just sets<br> >>>> a path for= URIs below it.<br> >>>><br> >>>> -- <br> >>>><br> >>>> On 5/3/201= 7 3:42 PM, Hugh Cayless wrote:<br> >>>>> Well, = we don't know about the third one, except that it<br> >>>>> points= to whatever element *in the same document* has the<br> >>>>> @xml:i= d "apple". When an application attempts to<br> >>>>> derefe= rence it, it should make the URI in @ref absolute<br> >>>>> and ch= eck it against the base<br> >>>>> (<a hr= ef=3D""></a>http://www.dictionary.com/words/a.html<br> >>>>> <<a= href=3D"http://www.dictionary.com/words/a.html">http://www.dictionary.com/= words/a.html</a>>), discover they<br> >>>>> are id= entical, decide it doesn't need to fetch anything,<br> >>>>> and go= looking in the current document for the element<br> >>>>> with t= he id "apple".<br> >>>>> On Wed= , May 3, 2017 at 3:27 PM, John P. McCaskey<br> >>>>> <ma= [email protected]<br> >>>>> <<a= href=3D"mailto:[email protected]">mailto:[email protected]</= a>>> wrote:<br> >>>>><br> >>>>> &= nbsp; Are people proposing that these targets do not all<br> >>>>> &= nbsp; resolve to the same<br> >>>>> &= nbsp; <a href=3D"http://www.dictionary.com/words/a.html#apple">= http://www.dictionary.com/words/a.html#apple</a><br> >>>>> &= nbsp; <<a href=3D"http://www.dictionary.com/words/a.html#app= le">http://www.dictionary.com/words/a.html#apple</a>>? <div<br> >>>>> &= nbsp; xml:base=3D"<a href=3D"http://www.dictionary.com/">h= ttp://www.dictionary.com/</a>"<br> >>>>> &= nbsp; <<a href=3D"http://www.dictionary.com/">http://www.dic= tionary.com/</a>>> <p xml:base=3D"words/"><br> >>>>> &= nbsp; <ref target=3D"a.html#apple">apple</re= f> </p> </div><br> >>>>> &= nbsp; <div xml:base=3D"<a href=3D"http://www.dictionary= .com/words/">http://www.dictionary.com/words/</a>"<br> >>>>> &= nbsp; <<a href=3D"http://www.dictionary.com/words/">http://w= ww.dictionary.com/words/</a>>> <p<br> >>>>> &= nbsp; xml:base=3D"a.html"> <ref target=3D"= #apple">apple</ref><br> >>>>> &= nbsp; </p> </div> <div<br> >>>>> &= nbsp; xml:base=3D"<a href=3D"http://www.dictionary.com/wor= ds/a.html">http://www.dictionary.com/words/a.html</a>"<br> >>>>> &= nbsp; <<a href=3D"http://www.dictionary.com/words/a.html">ht= tp://www.dictionary.com/words/a.html</a>>> <p> <ref<br> >>>>> &= nbsp; target=3D"#apple">apple</ref> </p&g= t; </div> <div<br> >>>>> &= nbsp; xml:base=3D"<a href=3D"http://www.dictionary.com/">h= ttp://www.dictionary.com/</a>"<br> >>>>> &= nbsp; <<a href=3D"http://www.dictionary.com/">http://www.dic= tionary.com/</a>>> <p> <ref<br> >>>>> &= nbsp; target=3D"words/a.html#apple">apple</ref&= gt; </p> </div>--<br> >>>>><br> <br> ------------------------------<br> <br> Date: Thu, 4 May 2017 11:37:19 -0600<br> From: "C. M. Sperberg-McQueen" <cmsmcq@BLACK= MESATECH.COM><br> Subject: Re: @xml:base with @rendition (and maybe other pointers)<br> <br> > On May 3, 2017, at 5:53 PM, John P. McCaskey <mailbox@JOHNMCCASKEY.= COM> wrote:<br> > <br> > So, bottom line: A standalone fragment identifier refers to the loaded= document and all the xml:base values above it in the hierarchy are irrelev= ant. Encoders cannot use xml:base to direct a standalone #fragment value to= a location outside the loaded document.<br> > <br> > Is that right?<br> <br> Yes and no. For some purposes, the ways in which the answer is 'no'<b= r> are pedantic and can be ignored; for others they seem important.<br> I did not respond to your summary yesterday, because objecting to <br> the wording you used seemed unnecessarily pedantic. Also, I <br> overlooked the second sentence, which I think is the wrong conclusion<br> to draw. <br> <br> Given the following fragment of resource <a href=3D"http://example.org/eg.x= ml">http://example.org/eg.xml</a><br> <br> <div xml:base=3D"<a href=3D"http://www.dictionary.com/a.html= ">http://www.dictionary.com/a.html</a>"><br> <p><br> <ref target=3D"#apple">Apple= </ref><br> <ref target=3D"a.html#avocado"&= gt;Avocado</ref><br> <ref target=3D"<a href=3D"http://www= .dictionary.com/a.html#anise">Anise</ref">http://www.dictionary.= com/a.html#anise">Anise</ref</a>><br> </p><br> </div><br> <br> we can consider two ways of interpreting the target attributes.<br> <br> Note that the discussion below ignores some possibly salient facts:<br> <br> - URIs can denote different resources at different moments.<br> (The discussion assumes the URI-resource mapping is not = changing.)<br> <br> - A given resource can have multiple representations. (The<br> discussion ignores any resulting complications.)<br> <br> - URIs whose path component ends in .xml and .html do not<br> necessarily have particular MIME types, so there i= s no guarantee<br> that a fragment identifier like #apple will have s= imilar<br> meanings. (The discussion assumes that fragm= ent identifiers<br> point to elements assigned IDs by the HTML 'id' at= tribute<br> and/or the xml:id attribute.) &nb= sp; <br> <br> Interpretation 1 ('xml:base values are irrelevant'). Ignore xml:base<= br> when resolving '#apple' [but not when resolving other relative<br> references]. The target attributes are interpreted as denoting<br> <br> (a) <a href=3D"http://example.org/eg.xml#apple">http://e= xample.org/eg.xml#apple</a><br> (b) <a href=3D"http://www.dictionary.com/a.html#avocado"= >http://www.dictionary.com/a.html#avocado</a><br> (c) <a href=3D"http://www.dictionary.com/a.html#anise">h= ttp://www.dictionary.com/a.html#anise</a><br> <br> None of these have anything to do with any of:<br> <br> (d) <a href=3D"http://www.dictionary.com/a.html#apple">h= ttp://www.dictionary.com/a.html#apple</a><br> (e) <a href=3D"http://example.org/eg.xml#avocado">http:/= /example.org/eg.xml#avocado</a><br> (f) <a href=3D"http://example.org/eg.xml#anise">http://e= xample.org/eg.xml#anise</a> <br> <br> Of these, (a) is a same-document reference and RFC 3986 says it<br> "should" be dereferenced without a new retrieval action. If= a new<br> retrieval action is nevertheless launched, the resource retrieved is<br> (a).<br> <br> [It is not clear to me whether the XVAI ('xml:base values are<br> irrelevant') interpretation takes a position on whether any of these<br> other than (a) are same-document references.]<br> <br> Interpretation 2 ('same-document references can be surprising', or<br> SRCBS). Resolve all relative references against the base URI in the<b= r> usual way. Dereference same-document references either by looking in<= br> the same document (as recommended by RFC 3986) or by launching a new<br> retrieval operation.<br> <br> The target attributes are resolved to the absolute forms<br> <br> (d) <a href=3D"http://www.dictionary.com/a.html#apple">h= ttp://www.dictionary.com/a.html#apple</a><br> (b) <a href=3D"http://www.dictionary.com/a.html#avocado"= >http://www.dictionary.com/a.html#avocado</a><br> (c) <a href=3D"http://www.dictionary.com/a.html#anise">h= ttp://www.dictionary.com/a.html#anise</a><br> <br> All of these are same-document references, so according to RFC 3986,<br> they should be dereferenced without a new retrieval action. If a<br> retrieval action is nevertheless launched, it will go to URIs (d),<br> (b), (c) respectively, not (a), (e), (f). From the fact that (d),<br> (b), and (c) can be dereferenced without a new retrieval, it follows<br> (as far as I can tell) that these three resources can also be denoted<br> by URIs (a), (e), (f).<br> <br> The XVAI and SRCBS interpretations agree on the following proposition,<br> which has important relevance for operations on the data:<br> <br> P1 The relative reference target=3D"#apple" can be dereferenced b= y<br> locating the element in the current document with xml:id=3D"apple"= ;, if<br> such an element exists.<br> <br> For people whose main interest is the truth or falsity of that<br> proposition, then, the answer is "yes, that's right" -- the effec= t is<br> the same, and all else is just pilpul.<br> <br> From P1, it follows (I think) that<br> <br> P2 The resource identified by target=3D"#apple" is identified by = the<br> absolute URI <a href=3D"http://example.org/eg.xml#apple">http://example.org= /eg.xml#apple</a> ((a) above).<br> <br> The two interpretations disagree, or seem to disagree, on a number of<br> other propositions, most obviously:<br> <br> P3 The relative reference '#apple' does not identify the resource<br> identifed by <a href=3D"http://www.dictionary.com/a.html#apple">http://www.= dictionary.com/a.html#apple</a>.<br> <br> XVAI does not actually entail P2, but it is compatible with P3. (To<b= r> reach P3 it is necessary to assume some rule like "No two URIs<br> identify the same thing" or "If we don't know that a URI identifi= es a<br> thing, then it does not identify that thing.") SRCBS entails the= <br> negation of P3.<br> <br> They also prescribe different URIs for the case that software<br> determines to perform a fresh retrieval action for the relative<br> reference #apple: XVAI prescribes the absolute URI (a), SRCBS<br> prescribes URI (d).<br> <br> I don=92t believe anyone has seriously suggested XVAI as the<br> relevant rule of interpretation for examples like the one given;<br> what I have suggested (and I have understood Hugh Cayless <br> to be agreeing with) is SRCBS. Operationally, they can have<br> similar results in some circumstances (specifically: they can <br> both result in no new retrieval action being undertaken in order<br> to dereference =91#apple=92), but they differ in ways which can be<br> critical.<br> <br> <br> ********************************************<br> C. M. Sperberg-McQueen<br> Black Mesa Technologies LLC<br> [email protected]<br> <a href=3D"http://www.blackmesatech.com">http://www.blackmesatech.com</a><b= r> ********************************************<br> <br> ------------------------------<br> <br> Date: Thu, 4 May 2017 14:28:37 -0400<br> From: Hugh Cayless <[email protected]><br> Subject: Re: @xml:base with @rendition (and maybe other pointers)<br> <br> That's a rather favorable interpretation on your part. One person agrees<br= > with you without elucidating, one says this discussion has jumped the shark= <br> (which is fair), and the third (Michael Kay) gives a fuller answer which<br= > adds up to "it depends". Michael Kay is quite correct that in the= context<br> where a document retrieval is *expected* to occur, the URI would indeed be<= br> computed with reference to its base and fetched.<br> <br> The thing is, I'm not aware of any TEI attributes or element/attribute<br> combinations which are defined as *forcing* a retrieval action. I'd be<br> 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<br> same-document references *mean* in the context of TEI documents with<br> @xml:base. I agree this is something we ought to make clear. I think there<= br> is some possibility of wiggle room, given that TEI has its own media type.<= br> But I also think that we'd be better off adhering to the letter of RFC<br> 3986. The use of same-document references in TEI documents is ubiquitous,<b= r> and I'm firmly against anything that might break them.<br> <br> For what it's worth, modern web browsers seem to agree with your<br> interpretation (mutatis mutandis=97HTML base is not @xml:base). As far as I= <br> can tell, probably because of a desire on the part of the Mozilla<br> developers back in the day to maintain compatibility with IE 4(!).[1]<br> <br> To further complicate matters, the author of RFC 3986, Roy Fielding, has<br= > said that using @xml:base in the way you propose, i.e. to enable shorthand<= br> references rather than to set a canonical URI for the current document, is<= br> abusive.[2]<br> <br> Given all this, I still agree with Michael Sperberg-McQueen's fuller<br> explication of the issues at hand. I would interpret same-document<br> references as pointing to the current document, with the caveat that there<= br> might be, now or in the future, certain pointer attributes or<br> element/attribute combinations that mandate a retrieval action. Such a<br> retrieval would necessarily use whatever base was defined for the URI in<br= > question.<br> <br> References:<br> 1.<br> <a href=3D"http://w3future.com/weblog/2005/01/13.xml#stillBugsInTheImplemen= tationOfHtmlHyperlinks">http://w3future.com/weblog/2005/01/13.xml#stillBugs= InTheImplementationOfHtmlHyperlinks</a><br> 2. <a href=3D"http://w3future.com/weblog/2005/08/14.xml#howToUseBaseUris">h= ttp://w3future.com/weblog/2005/08/14.xml#howToUseBaseUris</a><br> <br> On Thu, May 4, 2017 at 10:16 AM, John P. McCaskey <mailbox@johnmccaskey.= com><br> wrote:<br> <br> > I asked about this over at XML-DEV, <a href=3D"http://lists.xml.org/ar= chives/">http://lists.xml.org/archives/</a><br> > xml-dev/201705/msg00008.html.<br> ><br> > Opinion there is with me and opposite the majority here.<br> ><br> > Readers there don=92t seem to think there is anything to debate. I got= one<br> > short answer and one dismissive comment about =94questions that simple= .=94<br> > Someone take a look and be sure I didn=92t word my question unfairly.<= br> > Whichever interpretation TEI adopts, sounds like it should be document= ed<br> > in the Guidelines or a note somewhere.<br> ><br> > If the McCaskey/XML-DEV interpretation is adopted, the GitHub issue I<= br> > posted about @rendition stands. If not, that issue goes away.<br> ><br> > John<br> ><br> ><br> ><br> > On 5/3/2017 8:03 PM, Hugh Cayless wrote:<br> ><br> > Those are the cards we've been dealt, yeah.<br> ><br> > Sent from my phone.<br> ><br> > On May 3, 2017, at 19:53, John P. McCaskey <[email protected]= M><br> > wrote:<br> ><br> > So, bottom line: A standalone fragment identifier refers to the loaded= <br> > document and all the xml:base values above it in the hierarchy are<br> > irrelevant. Encoders cannot use xml:base to direct a standalone #fragm= ent<br> > value to a location outside the loaded document.<br> ><br> > Is that right?<br> ><br> > --<br> ><br> ><br> > On 5/3/2017 6:20 PM, Hugh Cayless wrote:<br> ><br> > No. This clarifies the expected behavior when (e.g.) you have @xml:bas= e=3D"#frag".<br> > It says nothing whatever about <p rendition=3D"#foo">.= I don't think these<br> > specifications interact in the way you're positing. Quite the opposite= .<br> ><br> > On Wed, May 3, 2017 at 6:13 PM, John P. McCaskey <mailbox@johnmccas= key.com<br> > > wrote:<br> ><br> >> The special behavior of same-document references in RFC 3986 is di= savowed<br> >> by W3C:<br> >><br> >> 4.4 Interpretation of same-document references<br> >><br> >> RFC 3986 defines certain relative URI references, in particular th= e empty<br> >> string and those of the form #fragment, as same-document reference= s.<br> >> Dereferencing of same-document references is handled specially. Ho= wever,<br> >> their use as the value of an *xml:base attribute does not* *involv= e *dereferencing,<br> >> and XML Base processors should resolve them in the usual way. In<b= r> >> particular, xml:base=3D"" does not reset the base URI to= that of the<br> >> containing document.<br> >><br> >> Note:<br> >><br> >> Some existing processors do treat these xml:base values as resetti= ng the<br> >> base URI to that of the containing document, so the use of such va= lues is<br> >> strongly discouraged.<br> >><br> >> This says:<br> >><br> >> RFC 3986 defines special =93dereferencing=94 of empty strings and = #fragments.<br> >> But over here in XML-land, we don=92t do =93dereferencing.=93 That= =92s not a word<br> >> we use here. Ignore that stuff about same-document references. Jus= t resolve<br> >> empty strings and #fragments as specified in the W3C Recommendatio= n above.<br> >> And those of you who did carry that stuff over from 3986 to XML-la= nd, shame<br> >> on you. You messed things up for the rest of us.<br> >><br> >><br> >> A note has:<br> >><br> >> 5. The meanings of xml:base=3D"" and xml:base=3D"#f= rag" have been clarified;<br> >><br> >> This says:<br> >><br> >> In this second version of this recommendation, we added paragraph = 4.4<br> >> specifically to get you 3986 people to stop polluting our W3C with= your<br> >> special cases. Stop doing that.<br> >><br> >> No?<br> >><br> >> -- John<br> >><br> >><br> >><br> >><br> >><br> >><br> >> On 5/3/2017 5:09 PM, Hugh Cayless wrote:<br> >><br> >> That's exactly what it does. It's just that the behavior of same-d= ocument<br> >> references is prescribed in such a way that they end up resolving = to the<br> >> current document regardless of the value of the @xml:base.<br> >><br> >> Put another way, @xml:base has an influence on what the client<br> >> application will retrieve when it dereferences a URI and retrieves= the<br> >> referenced document, but in the case of same-document references n= o such<br> >> retrieval is expected to occur=97it's assumed the client already h= as the<br> >> document.<br> >><br> >> On Wed, May 3, 2017 at 4:29 PM, John P. McCaskey <<br> >> [email protected]> wrote:<br> >><br> >>> Oh. I thought it obvious they all resolved the same.<br> >>><br> >>> I think the same about this one. You think otherwise?<br> >>><br> >>> <div xml:base=3D"<a href=3D"http://www.myteiproject.co= m/">http://www.myteiproject.com/</a>" <<a href=3D"http://www.myteip= roject.com/">http://www.myteiproject.com/</a>><br> >>> <div xml:base=3D"images/"><br> >>> <div><br> >>> <graphic url=3D"lo= go.jpg"><br> >>> </div><br> >>> <div xml:base=3D"<a href=3D"ht= tp://www.dictionary.com/words/">http://www.dictionary.com/words/</a>"&= gt;<br> >>> <p xml:base=3D"a.h= tml"><br> >>> <ref target= =3D"#apple">apple</ref><br> >>> </p><br> >>> </div><br> >>> </div><br> >>> </div><br> >>><br> >>> I didn=92t think xml:base had any necessary relation to the cu= rrent<br> >>> document. I thought in XML (not HTML), it just sets a path for= URIs below<br> >>> it.<br> >>><br> >>> --<br> >>> On 5/3/2017 3:42 PM, Hugh Cayless wrote:<br> >>><br> >>> Well, we don't know about the third one, except that it points= to<br> >>> whatever element *in the same document* has the @xml:id "= apple". When<br> >>> an application attempts to dereference it, it should make the = URI in @ref<br> >>> absolute and check it against the base (<a href=3D""></a>http:= //www.dictionary.com/wor<br> >>> ds/a.html), discover they are identical, decide it doesn't nee= d to<br> >>> fetch anything, and go looking in the current document for the= element with<br> >>> the id "apple".<br> >>> On Wed, May 3, 2017 at 3:27 PM, John P. McCaskey <<br> >>> [email protected]> wrote:<br> >>>><br> >>>> Are people proposing that these targets do not all resolve= <br> >>>> to the same <a href=3D"http://www.dictionary.com/words/a.h= tml#apple?">http://www.dictionary.com/words/a.html#apple?</a><br> >>>> <div xml:base=3D"<a href=3D"http://www.dictionary.= com/">http://www.dictionary.com/</a>" <<a href=3D"http://www.dictio= nary.com/">http://www.dictionary.com/</a>>><br> >>>> <p xml:base=3D"words/"= ;><br> >>>> <ref ta= rget=3D"a.html#apple">apple</ref><br> >>>> </p><br> >>>> </div><br> >>>><br> >>>> <div xml:base=3D"<a href=3D"http://www.dictionary.= com/words/">http://www.dictionary.com/words/</a>" <<a href=3D"http:= //www.dictionary.com/words/">http://www.dictionary.com/words/</a>>><b= r> >>>> <p xml:base=3D"a.html"= ;><br> >>>> <ref ta= rget=3D"#apple">apple</ref><br> >>>> </p><br> >>>> </div><br> >>>><br> >>>> <div xml:base=3D"<a href=3D"http://www.dictionary.= com/words/a.html">http://www.dictionary.com/words/a.html</a>" <<a h= ref=3D"http://www.dictionary.com/words/a.html">http://www.dictionary.com/wo= rds/a.html</a>>><br> >>>> <p><br> >>>> <ref ta= rget=3D"#apple">apple</ref><br> >>>> </p><br> >>>> </div><br> >>>><br> >>>> <div xml:base=3D"<a href=3D"http://www.dictionary.= com/">http://www.dictionary.com/</a>" <<a href=3D"http://www.dictio= nary.com/">http://www.dictionary.com/</a>>><br> >>>> <p><br> >>>> <ref ta= rget=3D"words/a.html#apple">apple</ref><br> >>>> </p><br> >>>> </div><br> >>>> --<br> >>>><br> >>>><br> <br> ------------------------------<br> <br> Date: Thu, 4 May 2017 15:31:42 -0400<br> From: "John P. McCaskey" <mailbox@JOHNMCCASK= EY.COM><br> Subject: Re: @xml:base with @rendition (and maybe other pointers)<br> <br> What is the short bottom-line guidance for someone trying to encode a <br> document? Is it this?<br> <br> To point inside a TEI document, as for @rendition, use p= ointers of<br> the form #destination. Any later changes to xml:base val= ues will not<br> mess up your internal # pointers.<br> <br> Don=92t try to point outside your TEI document by using = xml:base plus<br> a #destination in the pointer attribute. No xml:base att= ribute will<br> be prepended to a pointer that begins with a #.<br> <br> Even if I and others find that idiosyncratic and surprising, it=92s <br> unambiguous, has practical benefits, requires no knowledge of RFCs or <br> W3C specs, is easy to articulate, and is easy to encode to.<br> <br> John<br> <br> <br> <br> On 5/4/2017 2:28 PM, Hugh Cayless wrote:<br> > That's a rather favorable interpretation on your part. One person <br> > agrees with you without elucidating, one says this discussion has <br> > jumped the shark (which is fair), and the third (Michael Kay) gives a = <br> > fuller answer which adds up to "it depends". Michael Kay is = quite <br> > correct that in the context where a document retrieval is *expected* <= br> > to occur, the URI would indeed be computed with reference to its base = <br> > and fetched.<br> ><br> > The thing is, I'm not aware of any TEI attributes or element/attribute= <br> > combinations which are defined as *forcing* a retrieval action. I'd be= <br> > 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 <br= > > what same-document references *mean* in the context of TEI documents <= br> > with @xml:base. I agree this is something we ought to make clear. I <b= r> > think there is some possibility of wiggle room, given that TEI has its= <br> > own media type. But I also think that we'd be better off adhering to <= br> > the letter of RFC 3986. The use of same-document references in TEI <br= > > documents is ubiquitous, and I'm firmly against anything that might <b= r> > break them.<br> ><br> > For what it's worth, modern web browsers seem to agree with your <br> > interpretation (mutatis mutandis=97HTML base is not @xml:base). As far= <br> > as I can tell, probably because of a desire on the part of the Mozilla= <br> > developers back in the day to maintain compatibility with IE 4(!).[1]<= br> ><br> > To further complicate matters, the author of RFC 3986, Roy Fielding, <= br> > has said that using @xml:base in the way you propose, i.e. to enable <= br> > shorthand references rather than to set a canonical URI for the <br> > current document, is abusive.[2]<br> ><br> > Given all this, I still agree with Michael Sperberg-McQueen's fuller <= br> > explication of the issues at hand. I would interpret same-document <br= > > references as pointing to the current document, with the caveat that <= br> > there might be, now or in the future, certain pointer attributes or <b= r> > element/attribute combinations that mandate a retrieval action. Such a= <br> > retrieval would necessarily use whatever base was defined for the URI = <br> > in question.<br> ><br> > References:<br> > 1. <br> > <a href=3D"http://w3future.com/weblog/2005/01/13.xml#stillBugsInTheImp= lementationOfHtmlHyperlinks"> http://w3future.com/weblog/2005/01/13.xml#stillBugsInTheImplementationOfHtm= lHyperlinks</a><br> > 2. <a href=3D"http://w3future.com/weblog/2005/08/14.xml#howToUseBaseUr= is">http://w3future.com/weblog/2005/08/14.xml#howToUseBaseUris</a><br> ><br> > On Thu, May 4, 2017 at 10:16 AM, John P. McCaskey <br> > <[email protected] <<a href=3D"mailto:mailbox@johnmccaske= y.com">mailto:[email protected]</a>>> wrote:<br> ><br> > I asked about this over at XML-DEV,<br> > <a href=3D"http://lists.xml.org/archives/xml-d= ev/201705/msg00008.html">http://lists.xml.org/archives/xml-dev/201705/msg00= 008.html</a><br> > <<a href=3D"http://lists.xml.org/archives/x= ml-dev/201705/msg00008.html">http://lists.xml.org/archives/xml-dev/201705/m= sg00008.html</a>>.<br> ><br> > Opinion there is with me and opposite the majo= rity here.<br> ><br> > Readers there don=92t seem to think there is a= nything to debate. I<br> > got one short answer and one dismissive commen= t about =94questions<br> > that simple.=94 Someone take a look and be sur= e I didn=92t word my<br> > question unfairly.<br> ><br> > Whichever interpretation TEI adopts, sounds li= ke it should be<br> > documented in the Guidelines or a note somewhe= re.<br> ><br> > If the McCaskey/XML-DEV interpretation is adop= ted, the GitHub<br> > issue I posted about @rendition stands. If not= , that issue goes away.<br> ><br> > John<br> ><br> ><br> ><br> > On 5/3/2017 8:03 PM, Hugh Cayless wrote:<br> >> Those are the cards we've been dealt, yeah= .<br> >><br> >> Sent from my phone.<br> >><br> >> On May 3, 2017, at 19:53, John P. McCaskey= <br> >> <[email protected] <<a href= =3D"mailto:[email protected]">mailto:[email protected]</a>>= ;> wrote:<br> >><br> >>> So, bottom line: A standalone fragment= identifier refers to the<br> >>> loaded document and all the xml:base v= alues above it in the<br> >>> hierarchy are irrelevant. Encoders can= not use xml:base to direct<br> >>> a standalone #fragment value to a loca= tion outside the loaded<br> >>> document.<br> >>><br> >>> Is that right?<br> >>><br> >>> --<br> >>><br> >>><br> >>> On 5/3/2017 6:20 PM, Hugh Cayless wrot= e:<br> >>>> No. This clarifies the expected be= havior when (e.g.) you have<br> >>>> @xml:base=3D"#frag". It = says nothing whatever about <p<br> >>>> rendition=3D"#foo">. = I don't think these specifications interact<br> >>>> in the way you're positing. Quite = the opposite.<br> >>>><br> >>>> On Wed, May 3, 2017 at 6:13 PM, Jo= hn P. McCaskey<br> >>>> <[email protected] <<= a href=3D"mailto:[email protected]">mailto:[email protected]<= /a>>> wrote:<br> >>>><br> >>>> The specia= l behavior of same-document references in RFC<br> >>>> 3986 is di= savowed by W3C:<br> >>>><br> >>>>  = ; 4.4 Interpretation of same-document references<br> >>>><br> >>>>  = ; RFC 3986 defines certain relative URI references, in<br> >>>>  = ; particular the empty string and those of the form<br> >>>>  = ; #fragment, as same-document references. Dereferencing<br> >>>>  = ; of same-document references is handled specially.<br> >>>>  = ; However, their use as the value of an *xml:base<br> >>>>  = ; attribute does not* *involve *dereferencing, and XML<br> >>>>  = ; Base processors should resolve them in the usual way.<br> >>>>  = ; In particular, xml:base=3D"" does not reset the bas= e URI<br> >>>>  = ; to that of the containing document.<br> >>>><br> >>>>  = ; Note:<br> >>>><br> >>>>  = ; Some existing processors do treat these xml:base values<br> >>>>  = ; as resetting the base URI to that of the containing<br> >>>>  = ; document, so the use of such values is strongly<br> >>>>  = ; discouraged.<br> >>>><br> >>>> This says:= <br> >>>><br> >>>>  = ; RFC 3986 defines special =93dereferencing=94 of empty<br> >>>>  = ; strings and #fragments. But over here in XML-land, we<br> >>>>  = ; don=92t do =93dereferencing.=93 That=92s not a word we use<br= > >>>>  = ; here. Ignore that stuff about same-document references.<br> >>>>  = ; Just resolve empty strings and #fragments as specified<br> >>>>  = ; in the W3C Recommendation above. And those of you who<br> >>>>  = ; did carry that stuff over from 3986 to XML-land, shame<br> >>>>  = ; on you. You messed things up for the rest of us.<br> >>>><br> >>>><br> >>>> A note has= :<br> >>>><br> >>>>  = ; 5. The meanings of xml:base=3D"" and xml:base=3D&qu= ot;#frag"<br> >>>>  = ; have been clarified;<br> >>>><br> >>>> This says:= <br> >>>><br> >>>>  = ; In this second version of this recommendation, we added<br> >>>>  = ; paragraph 4.4 specifically to get you 3986 people to<br> >>>>  = ; stop polluting our W3C with your special cases. Stop<br> >>>>  = ; doing that.<br> >>>><br> >>>> No?<br> >>>><br> >>>> -- John<br= > >>>><br> >>>><br> >>>><br> >>>><br> >>>><br> >>>><br> >>>> On 5/3/201= 7 5:09 PM, Hugh Cayless wrote:<br> >>>>> That's= exactly what it does. It's just that the behavior<br> >>>>> of sam= e-document references is prescribed in such a way<br> >>>>> that t= hey end up resolving to the current document<br> >>>>> regard= less of the value of the @xml:base.<br> >>>>><br> >>>>> Put an= other way, @xml:base has an influence on what the<br> >>>>> client= application will retrieve when it dereferences a<br> >>>>> URI an= d retrieves the referenced document, but in the case<br> >>>>> of sam= e-document references no such retrieval is expected<br> >>>>> to occ= ur=97it's assumed the client already has the document.<br> >>>>><br> >>>>> On Wed= , May 3, 2017 at 4:29 PM, John P. McCaskey<br> >>>>> <ma= [email protected]<br> >>>>> <<a= href=3D"mailto:[email protected]">mailto:[email protected]</= a>>> wrote:<br> >>>>><br> >>>>> &= nbsp; Oh. I thought it obvious they all resolved the same.<br> >>>>><br> >>>>> &= nbsp; I think the same about this one. You think otherwise?<br> >>>>><br> >>>>> &= nbsp; <div xml:base=3D"<a href=3D"http://www.myteiproje= ct.com/">http://www.myteiproject.com/</a>"<br> >>>>> &= nbsp; <<a href=3D"http://www.myteiproject.com/">http://www.m= yteiproject.com/</a>> <div<br> >>>>> &= nbsp; xml:base=3D"images/"> <div> <graphi= c url=3D"logo.jpg"><br> >>>>> &= nbsp; </div> <div xml:base=3D"<a href=3D""></a>ht= tp://www.dictionary.com/words/<br> >>>>> &= nbsp; <<a href=3D"http://dictionary.com/words/">http://dicti= onary.com/words/</a>>"> <p xml:base=3D"a.html"><= br> >>>>> &= nbsp; <ref target=3D"#apple">apple</ref> = </p> </div> </div><br> >>>>> &= nbsp; </div><br> >>>>><br> >>>>> &= nbsp; I didn=92t think xml:base had any necessary relation to<b= r> >>>>> &= nbsp; the current document. I thought in XML (not HTML), it<br> >>>>> &= nbsp; just sets a path for URIs below it.<br> >>>>><br> >>>>> &= nbsp; -- <br> >>>>><br> >>>>> &= nbsp; On 5/3/2017 3:42 PM, Hugh Cayless wrote:<br> >>>>>> &nb= sp; Well, we don't know about the third one, except that<= br> >>>>>> &nb= sp; it points to whatever element *in the same document*<= br> >>>>>> &nb= sp; has the @xml:id "apple". When an applicatio= n attempts<br> >>>>>> &nb= sp; to dereference it, it should make the URI in @ref<br> >>>>>> &nb= sp; absolute and check it against the base<br> >>>>>> &nb= sp; (<a href=3D""></a>http://www.dictionary.com/words/a.h= tml<br> >>>>>> &nb= sp; <<a href=3D"http://www.dictionary.com/words/a.html= ">http://www.dictionary.com/words/a.html</a>>), discover<br> >>>>>> &nb= sp; they are identical, decide it doesn't need to fetch<b= r> >>>>>> &nb= sp; anything, and go looking in the current document for<= br> >>>>>> &nb= sp; the element with the id "apple".<br> >>>>>> &nb= sp; On Wed, May 3, 2017 at 3:27 PM, John P. McCaskey<br> >>>>>> &nb= sp; <[email protected]<br> >>>>>> &nb= sp; <<a href=3D"mailto:[email protected]">mailt= o:[email protected]</a>>> wrote:<br> >>>>>><br> >>>>>> &nb= sp; Are people proposing that the= se targets do not<br> >>>>>> &nb= sp; all resolve to the same<br> >>>>>> &nb= sp; <a href=3D"http://www.diction= ary.com/words/a.html#apple">http://www.dictionary.com/words/a.html#apple</a= ><br> >>>>>> &nb= sp; <<a href=3D"http://www.dic= tionary.com/words/a.html#apple">http://www.dictionary.com/words/a.html#appl= e</a>>?<br> >>>>>> &nb= sp; <div xml:base=3D"<a h= ref=3D"http://www.dictionary.com/">http://www.dictionary.com/</a>"<br> >>>>>> &nb= sp; <<a href=3D"http://www.dic= tionary.com/">http://www.dictionary.com/</a>>> <p<br> >>>>>> &nb= sp; xml:base=3D"words/"= > <ref<br> >>>>>> &nb= sp; target=3D"a.html#apple&q= uot;>apple</ref> </p> </div><br> >>>>>> &nb= sp; <div xml:base=3D"<a h= ref=3D"http://www.dictionary.com/words/">http://www.dictionary.com/words/</= a>"<br> >>>>>> &nb= sp; <<a href=3D"http://www.dic= tionary.com/words/">http://www.dictionary.com/words/</a>>> <p<br> >>>>>> &nb= sp; xml:base=3D"a.html"= > <ref<br> >>>>>> &nb= sp; target=3D"#apple"&g= t;apple</ref> </p> </div> <div<br> >>>>>> &nb= sp; xml:base=3D"<a href=3D"h= ttp://www.dictionary.com/words/a.html">http://www.dictionary.com/words/a.ht= ml</a>"<br> >>>>>> &nb= sp; <<a href=3D"http://www.dic= tionary.com/words/a.html">http://www.dictionary.com/words/a.html</a>>>= ; <p><br> >>>>>> &nb= sp; <ref target=3D"#apple= ">apple</ref> </p> </div> <div<br> >>>>>> &nb= sp; xml:base=3D"<a href=3D"h= ttp://www.dictionary.com/">http://www.dictionary.com/</a>"<br> >>>>>> &nb= sp; <<a href=3D"http://www.dic= tionary.com/">http://www.dictionary.com/</a>>> <p> <ref<br> >>>>>> &nb= sp; target=3D"words/a.html#a= pple">apple</ref> </p><br> >>>>>> &nb= sp; </div>--<br> >>>>>><br> <br> ------------------------------<br> <br> Date: Thu, 4 May 2017 14:32:37 -0600<br> From: "C. M. Sperberg-McQueen" <cmsmcq@BLACK= MESATECH.COM><br> Subject: Re: @xml:base with @rendition (and maybe other pointers)<br> <br> > On May 4, 2017, at 12:28 PM, Hugh Cayless <[email protected]>= ; wrote:<br> > <br> > That's a rather favorable interpretation on your part. One person agre= es with you without elucidating,<br> <br> I=92m not sure this is true. What Eliot Kimber said is that in the co= ntext given, =91#apple=92 identifies the same thing as =91http://www.dictio= nary.com/a.html#apple'. Does that distinguish between the two (? are = there just two?) =97 does that distinguish among the various interpretations of the situation offered so far?<br> <br> I don=92t think so. I think the disagreement we have is not over the = statement affirmed by Eliot Kimber, but over the following two claims= :<br> <br> C1 In the context described, =91#apple=92 is a same-document referen= ce and<br> can therefore by definition be dereferenced without a new retrieval = action.<br> <br> C2 In the context described, =91#apple=92 does not refer to the elem= ent in the<br> current document with xml:id=3D=93apple=94 (if any); it cannot= be dereferenced <br> without a new retrieval action.<br> <br> I intend C1 as a representation of the interpretation of 3986 I=92ve been o= ffering, and C2 as a representation of the interpretation offered by John M= cCaskey. (SRCBS and XVAI, in my note of earlier today.<br> <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 reference to its base and fetched. <br> <br> The URI is *always* computed with reference to its base. <br> <br> Optimizations which produce the same result are, of course, allowed. = 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 =93defined to be within=94 the current document; in co= nsequence no new retrieval is necessary and a new retrieval should be avoid= ed. The 'should' here means that 3986 recommends that new retrievals be avoided, but does not forbid new retriev= als; if conforming processors or specs have good reason for launching new r= etrievals, that's not a violation 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 cl= aim by the XSLT spec that the relevant resource is not within the current d= ocument.)<br> <br> > <br> > 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 hap= py 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 wha= t 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 s= ome 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 bre= ak them.<br> <br> Is it clear what counts as breakage, here?<br> <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? Or is it the case that one interpretation will break some URI references, and a different in= terpretation will break others? <br> <br> When there are two possible interpreations of a given rule in a spec, it=92= s 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 docu= ments and not breaking them, but between breaking those belonging to one project and breaking those belonging to an= other project.<br> <br> > For what it's worth, modern web browsers seem to agree with your inter= pretation (mutatis mutandis=97HTML base is not @xml:base). As far as I can = tell, probably because of a desire on the part of the Mozilla developers ba= ck in the day to maintain compatibility with IE 4(!).[1]<br> <br> 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"> http://example.com/doc.html</a> containing <base href=3D=93http://exampl= e.org/base.html=94>, a link of the form <a href=3D=93#quovadis=94>= where does this connect to?</a> will go to =85 where? <br> <br> I think the two obvious things one might expect to see in the address bar a= fter traversing that link are<br> <br> <a href=3D"http://example.com/doc.html#quovadis">http://= example.com/doc.html#quovadis</a><br> <a href=3D"http://example.org/base.html#quovaids">http:/= /example.org/base.html#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? 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> <br> <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> Thank you for that reference. <br> <br> I think the rules in 3986 make perfect sense if one assumes Roy Fielding=92= s 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 whi= ch would otherwise be long is not a scenario worth bending over backwards for. (That is, it seems to m= e to simplify matters, rather than complicating them.)<br> <br> If one doesn=92t want to make that assumption, some relatively simple rules= like the following might go some distance towards reducing the likelihood = of unpleasant surprises:<br> <br> - Use the form =93#fragment=94 only for references to locations in t= he current document. These will always be same-document references wi= thin the meaning of RFC 3986.<br> - Use xml:base to set all but the last bit of the URI, but not to se= t a full document URI: xml:base=3D=93http://dictionary.example.org/en= tries/=93 with relative references to =93a.html#apple=94 and =93a.html#anod= yne=94 will be better than xml:base=3D=93http://dictionary.example.org/entr= ies/a.html=94 with relative referencs to =93#apple=94 and =93#anodyne=94. These wi= ll never be taken to be same-document references.<br> <br> Note, however, that while =93#fragment=94 will always be a same-document re= ference, it will ALSO always be a reference to the given fragment in the re= source identified by the base URI. If that=92s not logically the same= as the resource within which the reference occurs, you=92re playing with fire: RFC 3986 says =93#fragment=94 = =93should=94 be dereferenced without a new retrieval, not that it must be.&= nbsp; Any software will be perfectly within its rights to retrieve the base= URI and look for the fragment there.<br> <br> > <br> > References:<br> > 1. <a href=3D"http://w3future.com/weblog/2005/01/13.xml#stillBugsInThe= ImplementationOfHtmlHyperlinks"> http://w3future.com/weblog/2005/01/13.xml#stillBugsInTheImplementationOfHtm= lHyperlinks</a><br> > 2. <a href=3D"http://w3future.com/weblog/2005/08/14.xml#howToUseBaseUr= is">http://w3future.com/weblog/2005/08/14.xml#howToUseBaseUris</a> <br> <br> <br> ********************************************<br> C. M. Sperberg-McQueen<br> Black Mesa Technologies LLC<br> [email protected]<br> <a href=3D"http://www.blackmesatech.com">http://www.blackmesatech.com</a><b= r> ********************************************<br> <br> ------------------------------<br> <br> Date: Thu, 4 May 2017 14:42:11 -0600<br> From: "C. M. Sperberg-McQueen" <cmsmcq@BLACK= MESATECH.COM><br> Subject: Re: @xml:base with @rendition (and maybe other pointers)<br> <br> > On May 4, 2017, at 1:31 PM, John P. McCaskey <mailbox@JOHNMCCASKEY.= COM> wrote:<br> > <br> > What is the short bottom-line guidance for someone trying to encode a = document? Is it this?<br> > <br> > 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 y= our internal # pointers.<br> > <br> > Don=92t try to point outside your TEI document by using xml:base plus = a #destination in the pointer attribute. No xml:base attribute will be prep= ended to a pointer that begins with a #.<br> <br> No. Sorry. That=92s not the way it works, and I think thi= s discussion has already demonstrated that it=92s a dangerous way to descri= be the behavior. <br> <br> If you want to keep things simple for the encoders, I=92d rephrase this as = something like: Don=92t try to point outside your TEI document by usi= ng xml:base plus a #destination in the pointer attribute. It does not= have the desired meaning. Point outside your TEI document either using an absolute URI or an xml:base attribute plus th= e final part of the path (the =91file name=92 part) and the fragment identi= fier. So NOT <ptr xml:base=3D=93lib/foo.xml=94 target=3D=93#bar=94= /> but <ptr xml:base=3D=93lib/=94 target=3D=93foo.xml#bar=94/>.<br= > <br> <br> ********************************************<br> C. M. Sperberg-McQueen<br> Black Mesa Technologies LLC<br> [email protected]<br> <a href=3D"http://www.blackmesatech.com">http://www.blackmesatech.com</a><b= r> ********************************************<br> <br> ------------------------------<br> <br> Date: Thu, 4 May 2017 20:44:29 +0000<br> From: Martin Mueller <[email protected]&g= t;<br> Subject: Re: @xml:base with @rendition (and maybe other pointers)<br> <br> I=92m following this thread from a distance (much of it is way over my head= ), but it reminds me of something I=92ve said before. Every few months or s= o there is an extended discussion on the TEI list that raises a tough issue= . It would be helpful to the members at large if the Council assumed the responsibility for digesting such a di= scussion into a one or two-page summary. There might a special place = on the site for such papers. Sometimes these discussion reach agreement, so= metimes they just help clarify positions. <br> <br> The obvious objection to my suggestion is that the members of the Council h= ave other and more pressing things to do. On the other hand, documentation = is clearly a responsibility of the Council, and position papers of this typ= e are a kind of documentation. Or one could say =93Why don=92t the readers of the list take or make the time= to read the extended discussion?=94 A good question, but there is a very h= igh time cost involved in tracking a discussion that has half a dozen parti= cipants and dozens of entries. <br> <br> I can=92t be the only follower of this list who wouldn=92t be grateful for = a succinct account of =93what was all this about?=94<br> <br> On 5/4/17, 3:32 PM, "TEI (Text Encoding Initiative) public discussion = list on behalf of C. M. Sperberg-McQueen" <[email protected]= on behalf of [email protected]> wrote:<br> <br> > On May 4, 2017, at 12:28 PM, Hugh Cayless <philo= [email protected]> wrote:<br> > <br> > That's a rather favorable interpretation on your pa= rt. One person agrees with you without elucidating,<br> <br> I=92m not sure this is true. What Eliot Kimber sai= d is that in the context given, =91#apple=92 identifies the same thing as = =91https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__www.dictionary.com= _a.html-23apple&d=3DDwIFaQ&c=3DyHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012= z2PA6ws&r=3DrG8zxOdssqSzDRz4x1GLlmLOW60xyVXydxwnJZpkxbk&m=3DbLi7T2x= rOg4vVFRr7hE1SVQa7jmldPgLzCrevoRJWI4&s=3DOlhWZ8ch2cUtq8qgCtAvoznqSamkaD= 9OBrjp2Js-eJs&e=3D '. Does that distinguish between the two (? are there just two?) =97= does that distinguish among the various interpretations of the situation o= ffered so far?<br> <br> I don=92t think so. I think the disagreement we ha= ve is not over the statement affirmed by Eliot Kimber, but over the f= ollowing two claims:<br> <br> C1 In the context described, =91#apple=92 is= a same-document reference and<br> can therefore by definition be dereferenced = without a new retrieval action.<br> <br> C2 In the context described, =91#apple=92 do= es not refer to the element in the<br> current document with xml:id=3D=93apple=94 (= if any); it cannot be dereferenced <br> without a new retrieval action.<br> <br> I intend C1 as a representation of the interpretation of= 3986 I=92ve been offering, and C2 as a representation of the interpretatio= n offered by John McCaskey. (SRCBS and XVAI, in my note of earlier today.<b= r> <br> > one says this discussion has jumped the shark (whic= h 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 contex= t where a document retrieval is *expected* to occur, the URI would indeed be computed with reference to its base and fetched. <br> <br> The URI is *always* computed with reference to its base.= <br> <br> Optimizations which produce the same result are, of cour= se, allowed. The preceding paragraph is a claim about the meaning of = certain language constructs, not a claim about what the CPU and network con= troller do during evaluation 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 =93defined to be within=94 the curr= ent document; in consequence no new retrieval is necessary and a new retrie= val should be avoided. The 'should' here means that 3986 recommends that new retrievals be avoided, but does not forbid new re= trievals; if conforming processors or specs have good reason for launching = new retrievals, that's not a violation 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= current document.)<br> <br> > <br> > The thing is, I'm not aware of any TEI attributes o= r 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. <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 bette= r off adhering to the letter of RFC 3986. The use of same-document referenc= es in TEI documents is ubiquitous, and I'm firmly against anything that mig= ht break them.<br> <br> Is it clear what counts as breakage, here?<br> <br> If a given interpretation of the URI specs causes some U= RI references to break (by which I mean: to have an interpretation differen= t from what the encoders intended), can we be confident that a contrary int= erpretation will not break any? Or is it the case that one interpretation will break some URI references, and a different in= terpretation will break others? <br> <br> When there are two possible interpreations of a given ru= le in a spec, it=92s seldom the case that everyone interprets it the same w= ay. There is some risk that your choice does not lie between breaking= things in TEI documents and not breaking them, but between breaking those belonging to one project and breaking those belonging to an= other project.<br> <br> > For what it's worth, modern web browsers seem to ag= ree with your interpretation (mutatis mutandis=97HTML base is not @xml:base= ). As far as I can tell, probably because of a desire on the part of the Mo= zilla developers back in the day to maintain compatibility with IE 4(!).[1]<br> <br> Can you expound? <br> <br> Do you mean that in an HTML 4.01 or XHTML 1.0 document a= t <a href=3D"https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__example.= com_doc.html&d=3DDwIFaQ&c=3DyHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2P= A6ws&r=3DrG8zxOdssqSzDRz4x1GLlmLOW60xyVXydxwnJZpkxbk&m=3DbLi7T2xrOg= 4vVFRr7hE1SVQa7jmldPgLzCrevoRJWI4&s=3D29y8v-TK44tIIjTyqctxB4Lf9WPymQrVd= zrLIvEW6qI&e=3D"> https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__example.com_doc.html&= amp;d=3DDwIFaQ&c=3DyHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=3D= rG8zxOdssqSzDRz4x1GLlmLOW60xyVXydxwnJZpkxbk&m=3DbLi7T2xrOg4vVFRr7hE1SVQ= a7jmldPgLzCrevoRJWI4&s=3D29y8v-TK44tIIjTyqctxB4Lf9WPymQrVdzrLIvEW6qI&am= p;e=3D</a> containing <base href=3D=93https://urldefense.proofpoint.com/v2/url?u= =3Dhttp-3A__example.org_base.html-25EF-25BF-25BD&d=3DDwIFaQ&c=3DyHl= S04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=3DrG8zxOdssqSzDRz4x1GLlmLOW6= 0xyVXydxwnJZpkxbk&m=3DbLi7T2xrOg4vVFRr7hE1SVQa7jmldPgLzCrevoRJWI4&s= =3DlknBDjsTtVRI870bNMIn9dPdWUvd3whJSBhji92091Q&e=3D ��>, a link of the form <a href=3D=93#quovadis=94>w= here does this connect to?</a> will go to =85 where? <br> <br> I think the two obvious things one might expect to see i= n the address bar after traversing that link are<br> <br> <a href=3D"https://urldefense.pr= oofpoint.com/v2/url?u=3Dhttp-3A__example.com_doc.html-23quovadis&d=3DDw= IFaQ&c=3DyHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=3DrG8zxOdssq= SzDRz4x1GLlmLOW60xyVXydxwnJZpkxbk&m=3DbLi7T2xrOg4vVFRr7hE1SVQa7jmldPgLz= CrevoRJWI4&s=3D1hCsliHZFQuB2OctN_76mPFbm9rUqdBn1A2SVJccTFc&e=3D"> https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__example.com_doc.html-= 23quovadis&d=3DDwIFaQ&c=3DyHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6= ws&r=3DrG8zxOdssqSzDRz4x1GLlmLOW60xyVXydxwnJZpkxbk&m=3DbLi7T2xrOg4v= VFRr7hE1SVQa7jmldPgLzCrevoRJWI4&s=3D1hCsliHZFQuB2OctN_76mPFbm9rUqdBn1A2= SVJccTFc&e=3D</a> <br> <a href=3D"https://urldefense.pr= oofpoint.com/v2/url?u=3Dhttp-3A__example.org_base.html-23quovaids&d=3DD= wIFaQ&c=3DyHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=3DrG8zxOdss= qSzDRz4x1GLlmLOW60xyVXydxwnJZpkxbk&m=3DbLi7T2xrOg4vVFRr7hE1SVQa7jmldPgL= zCrevoRJWI4&s=3DCOMDCJ41VanHpbGX9WMOSGuIRx38Szt4ldxlhdtB8vs&e=3D"> https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__example.org_base.html= -23quovaids&d=3DDwIFaQ&c=3DyHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA= 6ws&r=3DrG8zxOdssqSzDRz4x1GLlmLOW60xyVXydxwnJZpkxbk&m=3DbLi7T2xrOg4= vVFRr7hE1SVQa7jmldPgLzCrevoRJWI4&s=3DCOMDCJ41VanHpbGX9WMOSGuIRx38Szt4ld= xlhdtB8vs&e=3D</a> <br> <br> In the first case, this will happen either after a docum= ent refresh or without a refresh (just scrolling to the place).<br> <br> If a browser shows one of these addresses, does that con= stitute a claim that the other identifies a different resource? Or do= es it only constitute a decision on the part of the browser about which of = the two possible paths to a given resource it should take?<br> <br> <br> > To further complicate matters, the author of RFC 39= 86, 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]<br> <br> Thank you for that reference. <br> <br> I think the rules in 3986 make perfect sense if one assu= mes Roy Fielding=92s principle that the base URI within a document should b= e the base URI of the document, and that using xml:base or html:base to sho= rten references which 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.)<br> <br> If one doesn=92t want to make that assumption, some rela= tively simple rules like the following might go some distance towards reduc= ing the likelihood of unpleasant surprises:<br> <br> - Use the form =93#fragment=94 only for refe= rences to locations in the current document. These will always be sam= e-document references within the meaning of RFC 3986.<br> - Use xml:base to set all but the last bit o= f the URI, but not to set a full document URI: xml:base=3D=93https://= urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__dictionary.example.org_entrie= s_&d=3DDwIFaQ&c=3DyHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r= =3DrG8zxOdssqSzDRz4x1GLlmLOW60xyVXydxwnJZpkxbk&m=3DbLi7T2xrOg4vVFRr7hE1= SVQa7jmldPgLzCrevoRJWI4&s=3DuiFZhf2CmFnQIHzkLrsBKwvBnPTf2AtYINKYtwKyWMI= &e=3D =93 with relative references to =93a.html#apple=94 and =93a.html#anodyne= =94 will be better than xml:base=3D=93https://urldefense.proofpoint.com/v2/= url?u=3Dhttp-3A__dictionary.example.org_entries_a.html&d=3DDwIFaQ&c= =3DyHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=3DrG8zxOdssqSzDRz4x1GL= lmLOW60xyVXydxwnJZpkxbk&m=3DbLi7T2xrOg4vVFRr7hE1SVQa7jmldPgLzCrevoRJWI4= &s=3DpNUfEVwlyFPDAjVMWdE4ChwxmVlqytmyd6fi54Odw5A&e=3D =94 with relative referencs to =93#apple=94 and =93#anodyne=94. Thes= e will never be taken to be same-document references.<br> <br> Note, however, that while =93#fragment=94 will always be= a same-document reference, it will ALSO always be a reference to the given= fragment in the resource identified by the base URI. If that=92s not= logically the same as the resource within which the reference occurs, you=92re playing with fire: RFC 3986 says =93#fragment=94 = =93should=94 be dereferenced without a new retrieval, not that it must be.&= nbsp; Any software will be perfectly within its rights to retrieve the base= URI and look for the fragment there.<br> <br> > <br> > References:<br> > 1. <a href=3D"https://urldefense.proofpoint.com/v2/= url?u=3Dhttp-3A__w3future.com_weblog_2005_01_13.xml-23stillBugsInTheImpleme= ntationOfHtmlHyperlinks&d=3DDwIFaQ&c=3DyHlS04HhBraes5BQ9ueu5zKhE7rt= NXt_d012z2PA6ws&r=3DrG8zxOdssqSzDRz4x1GLlmLOW60xyVXydxwnJZpkxbk&m= =3DbLi7T2xrOg4vVFRr7hE1SVQa7jmldPgLzCrevoRJWI4&s=3DEOYAXmorJnWNneuoby45= ZricHwP8Ll9_ub7gKR2Ck-4&e=3D"> https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__w3future.com_weblog_2= 005_01_13.xml-23stillBugsInTheImplementationOfHtmlHyperlinks&d=3DDwIFaQ= &c=3DyHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=3DrG8zxOdssqSzDR= z4x1GLlmLOW60xyVXydxwnJZpkxbk&m=3DbLi7T2xrOg4vVFRr7hE1SVQa7jmldPgLzCrev= oRJWI4&s=3DEOYAXmorJnWNneuoby45ZricHwP8Ll9_ub7gKR2Ck-4&e=3D</a> <br> > 2. <a href=3D"https://urldefense.proofpoint.com/v2/= url?u=3Dhttp-3A__w3future.com_weblog_2005_08_14.xml-23howToUseBaseUris&= d=3DDwIFaQ&c=3DyHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=3DrG8z= xOdssqSzDRz4x1GLlmLOW60xyVXydxwnJZpkxbk&m=3DbLi7T2xrOg4vVFRr7hE1SVQa7jm= ldPgLzCrevoRJWI4&s=3DpUcTcRc_mAHAy8r8nPCz8cD8nuQBDOqDvJ-37BCwJJQ&e= =3D"> https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__w3future.com_weblog_2= 005_08_14.xml-23howToUseBaseUris&d=3DDwIFaQ&c=3DyHlS04HhBraes5BQ9ue= u5zKhE7rtNXt_d012z2PA6ws&r=3DrG8zxOdssqSzDRz4x1GLlmLOW60xyVXydxwnJZpkxb= k&m=3DbLi7T2xrOg4vVFRr7hE1SVQa7jmldPgLzCrevoRJWI4&s=3DpUcTcRc_mAHAy= 8r8nPCz8cD8nuQBDOqDvJ-37BCwJJQ&e=3D</a> <br> <br> <br> ********************************************<br> C. M. Sperberg-McQueen<br> Black Mesa Technologies LLC<br> [email protected]<br> <a href=3D"https://urldefense.proofpoint.com/v2/url?u=3D= http-3A__www.blackmesatech.com&d=3DDwIFaQ&c=3DyHlS04HhBraes5BQ9ueu5= zKhE7rtNXt_d012z2PA6ws&r=3DrG8zxOdssqSzDRz4x1GLlmLOW60xyVXydxwnJZpkxbk&= amp;m=3DbLi7T2xrOg4vVFRr7hE1SVQa7jmldPgLzCrevoRJWI4&s=3DceMDgmbvrnWoyJV= Z8VidJIp4udgcdq0tzNL8qVw_itM&e=3D"> https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__www.blackmesatech.com= &d=3DDwIFaQ&c=3DyHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r= =3DrG8zxOdssqSzDRz4x1GLlmLOW60xyVXydxwnJZpkxbk&m=3DbLi7T2xrOg4vVFRr7hE1= SVQa7jmldPgLzCrevoRJWI4&s=3DceMDgmbvrnWoyJVZ8VidJIp4udgcdq0tzNL8qVw_itM= &e=3D</a> <br> ********************************************<br> <br> <br> ------------------------------<br> <br> Date: Thu, 4 May 2017 17:07:00 -0400<br> From: Hugh Cayless <[email protected]><br> Subject: Re: @xml:base with @rendition (and maybe other pointers)<br> <br> On Thu, May 4, 2017 at 4:32 PM, C. M. Sperberg-McQueen <<br> [email protected]> wrote:<br> <br> ><br> ><br> > > one says this discussion has jumped the shark (which is fair), an= d the<br> > third (Michael Kay) gives a fuller answer which adds up to "it de= pends".<br> > Michael Kay is quite correct that in the context where a document retr= ieval<br> > is *expected* to occur, the URI would indeed be computed with referenc= e to<br> > its base and fetched.<br> ><br> > The URI is *always* computed with reference to its base.<br> ><br> <br> Right. It's the "and fetched" part that's crucial. In a context w= here<br> retrieval is forced, if the base is different from the document URI you'd<b= r> expect to end up somewhere else.<br> <br> ><br> > Optimizations which produce the same result are, of course, allowed.&n= bsp; The<br> > preceding paragraph is a claim about the meaning of certain language<b= r> > constructs, not a claim about what the CPU and network controller do d= uring<br> > evaluation of an expression by a conforming processor.<br> ><br> > If it is then determined to be a same-document URI, the resource<br> > identified by that URI is then =93defined to be within=94 the current = document;<br> > in consequence no new retrieval is necessary and a new retrieval shoul= d be<br> > avoided. The 'should' here means that 3986 recommends that new r= etrievals<br> > be avoided, but does not forbid new retrievals; if conforming processo= rs or<br> > specs have good reason for launching new retrievals, that's not a viol= ation<br> > of the rules of 3986. The XSLT spec defines the document() funct= ion as<br> > always launching a new retrieval. (Note that this does not amoun= t to any<br> > claim by the XSLT spec that the relevant resource is not within the cu= rrent<br> > document.)<br> ><br> > ><br> > > The thing is, I'm not aware of any TEI attributes or element/attr= ibute<br> > combinations which are defined as *forcing* a retrieval action. I'd be= <br> > 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, bu= t what<br> > same-document references *mean* in the context of TEI documents with<b= r> > @xml:base. I agree this is something we ought to make clear. I think t= here<br> > is some possibility of wiggle room, given that TEI has its own media t= ype.<br> > But I also think that we'd be better off adhering to the letter of RFC= <br> > 3986. The use of same-document references in TEI documents is ubiquito= us,<br> > and I'm firmly against anything that might break them.<br> ><br> > Is it clear what counts as breakage, here?<br> ><br> <br> Well, from my selfish perspective, "breakage" mainly means we've = got to go<br> all over the Guidelines and add notes to the effect that '#fragment'<br> pointers may behave differently if @xml:base is set. To an extent, wanting<= br> to avoid this is sheer laziness on my part. But I'm also convinced that<br> <tei:ref target=3D"#foo"> in P5 is intended to mean the sam= e thing that <ref<br> target=3D"foo"> did in P4, when the value of @target was IDREF= S rather than<br> teidata.pointer+ (I believe you mentioned this earlier), and that the<b= r> introduction of @xml:base was not intended to affect that meaning. I think<= br> we're better off assuming that same-document references are referring to<br= > the document that contains them.<br> <br> <br> ><br> > If a given interpretation of the URI specs causes some URI references = to<br> > break (by which I mean: to have an interpretation different from what = the<br> > encoders intended), can we be confident that a contrary interpretation= will<br> > not break any? Or is it the case that one interpretation will br= eak some<br> > 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=92s<br> > seldom the case that everyone interprets it the same way. There = is some<br> > risk that your choice does not lie between breaking things in TEI docu= ments<br> > and not breaking them, but between breaking those belonging to one pro= ject<br> > and breaking those belonging to another project.<br> ><br> > > For what it's worth, modern web browsers seem to agree with your<= br> > interpretation (mutatis mutandis=97HTML base is not @xml:base). As far= as I<br> > can tell, probably because of a desire on the part of the Mozilla<br> > developers back in the day to maintain compatibility with IE 4(!).[1]<= br> ><br> > Can you expound?<br> ><br> > Do you mean that in an HTML 4.01 or XHTML 1.0 document at<br> > <a href=3D"http://example.com/doc.html">http://example.com/doc.html</a= > containing <base href=3D=93<br> > <a href=3D"http://example.org/base.html=94">http://example.org/base.ht= ml=94</a>>, a link of the form <a<br> > href=3D=93#quovadis=94>where does this connect to?</a> will g= o to =85 where?<br> ><br> <br> In my brief experimentation, Chrome, Firefox, and Safari will all load<br> <a href=3D"http://example.org/base.html#quovadis">http://example.org/base.h= tml#quovadis</a> in this case, rather than scroll to<br> the element with id=3D"quovadis" in the current page.<br> <br> ><br> > I think the two obvious things one might expect to see in the address = bar<br> > after traversing that link are<br> ><br> > <a href=3D"http://example.com/doc.html#quovadi= s">http://example.com/doc.html#quovadis</a><br> > <a href=3D"http://example.org/base.html#quovai= ds">http://example.org/base.html#quovaids</a><br> ><br> > In the first case, this will happen either after a document refresh or= <br> > without a refresh (just scrolling to the place).<br> ><br> > If a browser shows one of these addresses, does that constitute a clai= m<br> > that the other identifies a different resource? Or does it only = constitute<br> > a decision on the part of the browser about which of the two possible = paths<br> > to a given resource it should take?<br> ><br> > I think it means the browser implementers decided to favor stability o= ver<br> technical correctness.<br> <br> <br> ><br> > > To further complicate matters, the author of RFC 3986, Roy Fieldi= ng, has<br> > said that using @xml:base in the way you propose, i.e. to enable short= hand<br> > references rather than to set a canonical URI for the current document= , is<br> > abusive.[2]<br> ><br> > Thank you for that reference.<br> ><br> > I think the rules in 3986 make perfect sense if one assumes Roy Fieldi= ng=92s<br> > principle that the base URI within a document should be the base URI o= f the<br> > document, and that using xml:base or html:base to shorten references w= hich<br> > would otherwise be long is not a scenario worth bending over backwards= <br> > for. (That is, it seems to me to simplify matters, rather than<b= r> > complicating them.)<br> ><br> > If one doesn=92t want to make that assumption, some relatively simple = rules<br> > like the following might go some distance towards reducing the likelih= ood<br> > of unpleasant surprises:<br> ><br> > - Use the form =93#fragment=94 only for references to loca= tions in the<br> > current document. These will always be same-document references = within the<br> > meaning of RFC 3986.<br> > - Use xml:base to set all but the last bit of the URI, but= not to set a<br> > full document URI: xml:base=3D=93http://dictionary.example.org/e= ntries/=93<br> > with relative references to =93a.html#apple=94 and =93a.html#anodyne= =94 will be<br> > better than xml:base=3D=93http://dictionary.example.org/entries/a.html= =94 with<br> > relative referencs to =93#apple=94 and =93#anodyne=94. These wil= l never be taken<br> > to be same-document references.<br> ><br> > Note, however, that while =93#fragment=94 will always be a same-docume= nt<br> > reference, it will ALSO always be a reference to the given fragment in= the<br> > resource identified by the base URI. If that=92s not logically t= he same as<br> > the resource within which the reference occurs, you=92re playing with = fire:<br> > RFC 3986 says =93#fragment=94 =93should=94 be dereferenced without a n= ew retrieval,<br> > not that it must be. Any software will be perfectly within its r= ights to<br> > retrieve the base URI and look for the fragment there.<br> ><br> <br> I think this is perfectly reasonable. I believe we're justified in saying<b= r> what the TEI expects "#fragment" to mean in the context of a TEI = document,<br> but we can't guarantee that some piece of software that processes your<br> document won't make different decisions than we expect.<br> <br> ><br> > ><br> > > References:<br> > > 1. <a href=3D"http://w3future.com/weblog/2005/01/13.xml#">http://= w3future.com/weblog/2005/01/13.xml#</a><br> > stillBugsInTheImplementationOfHtmlHyperlinks<br> > > 2. <a href=3D"http://w3future.com/weblog/2005/08/14.xml#howToUseB= aseUris">http://w3future.com/weblog/2005/08/14.xml#howToUseBaseUris</a><br> ><br> ><br> > ********************************************<br> > C. M. Sperberg-McQueen<br> > Black Mesa Technologies LLC<br> > [email protected]<br> > <a href=3D"http://www.blackmesatech.com">http://www.blackmesatech.com<= /a><br> > ********************************************<br> ><br> ><br> <br> ------------------------------<br> <br> End of TEI-L Digest - 3 May 2017 to 4 May 2017 (#2017-101)<br> **********************************************************<br> </div> </span></font></div> </div> </body> </html> --_000_DB5PR03MB1544AD8AB48C04BC8B93D332CDEB0DB5PR03MB1544eurp_--