Re: @xml:base with @rendition (and maybe other pointers)
Hugh Cayless <[email protected]> Tue, 2 May 2017 17:39:13 -0400
| Newsgroups | gmane.text.tei.general |
|---|---|
| Message-ID | <[email protected]> |
--Apple-Mail-89E627C3-2215-4FEA-BDC7-4D9415C92DC7 Content-Type: text/plain; charset=cp932 Content-Transfer-Encoding: quoted-printable > On May 2, 2017, at 17:07, Syd Bauman <[email protected]> wrote: >=20 > Hugh -- >=20 > Where does it say the interpretation of a fragment ID *with respect > to its @xml:base* depends on the media type? I don't believe it does. I was looking at things like https://www.w3.org/TR/= fragid-best-practices/, which says that the behaviors with regard to fragmen= t references depend on the media type. To be sure, I'm not certain we'd actu= ally be free to define a custom behavior for fragment ids because we have to= follow the behaviors defined for XML. They're thinking particularly of case= s where you might not have the whole file.=20 I can't see how we could insist #word-type URIs would result in the retrieva= l of a different document. As Michael says, the assumption is that you've al= ready got the referenced document, even if the base points to a different on= e.=20 >=20 > John -- >=20 > Yes, I think a base URI is specific to an element (which might be the > whole document, might not). >=20 > Yes, I think the quoted passage is saying that a fragment ID points > to the same document as the base URI in effect. >=20 > No, I'm not at all sure the paragraph in the xml:base spec does say > that fragment IDs should honor the xml:base. But then again, I'm not > at all sure it *doesn't* say that. I can't read RFC=20 >=20 >> In XML, isn=81ft =81gbase URI=81g something specific to an element, not t= o >> the document? >>=20 >> If so, the passage quoted is not saying that fragment IDs can point >> only to the document they are in, just that a fragment ID points to >> the same document as the base URI in effect for the containing XML >> element. >>=20 >> Doesn=81ft this paragraph <https://www.w3.org/TR/xmlbase/#matching> >> say fragment IDs should honor the complete xml:base value in effect >> for the attribute=81fs element? --Apple-Mail-89E627C3-2215-4FEA-BDC7-4D9415C92DC7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D= utf-8"></head><body dir=3D"auto"><div><span></span></div><div><meta http-equ= iv=3D"content-type" content=3D"text/html; charset=3Dutf-8"><div><br></div><d= iv>On May 2, 2017, at 17:07, Syd Bauman <<a href=3D"mailto:s.bauman@NORTH= EASTERN.EDU">[email protected]</a>> wrote:<br><br></div><blockquo= te type=3D"cite"><div><span>Hugh --</span><br><span></span><br><span>Where d= oes it say the interpretation of a fragment ID *with respect</span><br><span= >to its @xml:base* depends on the media type?</span><br></div></blockquote><= div><br></div>I don't believe it does. I was looking at things like <a h= ref=3D"https://www.w3.org/TR/fragid-best-practices/">https://www.w3.org/TR/f= ragid-best-practices/</a>, which says that the behaviors with regard to frag= ment references depend on the media type. To be sure, I'm not certain we'd a= ctually be free to define a custom behavior for fragment ids because we have= to follow the behaviors defined for XML. They're thinking particularly of c= ases where you might not have the whole file. </div><div><br></div><div= >I can't see how we could insist #word-type URIs would result in the retriev= al of a different document. As Michael says, the assumption is that you've a= lready got the referenced document, even if the base points to a different o= ne. <br><blockquote type=3D"cite"><div><span></span><br><span>John --</= span><br><span></span><br><span>Yes, I think a base URI is specific to an el= ement (which might be the</span><br><span>whole document, might not).</span>= <br><span></span><br><span>Yes, I think the quoted passage is saying that a f= ragment ID points</span><br><span>to the same document as the base URI in ef= fect.</span><br><span></span><br><span>No, I'm not at all sure the paragraph= in the xml:base spec does say</span><br><span>that fragment IDs should hono= r the xml:base. But then again, I'm not</span><br><span>at all sure it *does= n't* say that.</span><br></div></blockquote><div><br></div>I can't read RFC&= nbsp;<br><blockquote type=3D"cite"><div><span></span><br><blockquote type=3D= "cite"><span>In XML, isn=E2=80=99t =E2=80=9Cbase URI=E2=80=9C something spec= ific to an element, not to</span><br></blockquote><blockquote type=3D"cite">= <span>the document?</span><br></blockquote><blockquote type=3D"cite"><span><= /span><br></blockquote><blockquote type=3D"cite"><span>If so, the passage qu= oted is not saying that fragment IDs can point</span><br></blockquote><block= quote type=3D"cite"><span>only to the document they are in, just that a frag= ment ID points to</span><br></blockquote><blockquote type=3D"cite"><span>the= same document as the base URI in effect for the containing XML</span><br></= blockquote><blockquote type=3D"cite"><span>element.</span><br></blockquote><= blockquote type=3D"cite"><span></span><br></blockquote><blockquote type=3D"c= ite"><span>Doesn=E2=80=99t this paragraph <<a href=3D"https://www.w3.org/= TR/xmlbase/#matching">https://www.w3.org/TR/xmlbase/#matching</a>></span>= <br></blockquote><blockquote type=3D"cite"><span>say fragment IDs should hon= or the complete xml:base value in effect</span><br></blockquote><blockquote t= ype=3D"cite"><span>for the attribute=E2=80=99s element?</span><br></blockquo= te></div></blockquote></div></body></html>= --Apple-Mail-89E627C3-2215-4FEA-BDC7-4D9415C92DC7--