@xml:base with @rendition (and maybe other pointers)

classic Classic list List threaded Threaded
71 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

@xml:base with @rendition (and maybe other pointers)

John P. McCaskey-2

@rendition has datatype teidata.pointer. Pointers can point to locations either within the current document or elsewhere. They should be expanded with any @<a class="moz-txt-link-freetext" href="xml:base">xml:base attributes up the XML tree.

But @rendition is supposed to point to an element in the tagsDecl element, normally within the same document, though presumably it could be the tagsDecl in some other document.

My question: Is it really the case that a rendition pointer should honor parent @<a class="moz-txt-link-freetext" href="xml:base">xml:base attributes?

I guess the theoretical answer is yes, but I can imagine cases where the @<a class="moz-txt-link-freetext" href="xml:base">xml:base attributes are primarily for setting image paths, .xml directories, and http addresses, and the coder does not really intend the @rendition attributes to point externally.

Thoughts?

John

Reply | Threaded
Open this post in threaded view
|

Re: @xml:base with @rendition (and maybe other pointers)

Piotr Banski
One thought is to introduce a tei.localref datatype that would be
defined as an XML name prepended with a '#'. That could help in cases
where one would like to create (by means of Schematron[1]) an analogy to
the IDREF mechanism. And since the type wouldn't be defined as an URI,
xml:base expansion wouldn't apply to it.

[1] Maybe the Schematron check should even be an internal part of the
definition of that datatype, to force document() -- except I am not so
sure how "document()" would behave in such cases. I'd love to be
enlightened.

Musing aloud,
   Piotr

On 05/02/17 14:46, John P. McCaskey wrote:

> @rendition has datatype teidata.pointer. Pointers can point to locations
> either within the current document or elsewhere. They should be expanded
> with any @xml:base attributes up the XML tree.
>
> But @rendition is supposed to point to an element in the tagsDecl
> element, normally within the same document, though presumably it could
> be the tagsDecl in some other document.
>
> My question: Is it really the case that a rendition pointer should honor
> parent @xml:base attributes?
>
> I guess the theoretical answer is yes, but I can imagine cases where the
> @xml:base attributes are primarily for setting image paths, .xml
> directories, and http addresses, and the coder does not really intend
> the @rendition attributes to point externally.
>
> Thoughts?
>
> John
>
Reply | Threaded
Open this post in threaded view
|

Re: @xml:base with @rendition (and maybe other pointers)

Martin Holmes
I think the same rules should apply to all pointer types. John is right
to remind us of something I've been guilty of many times over: writing
pointer-handling code that doesn't think to look at @xml:base. But
that's my fault, not the fault of XML or TEI. I think the semantics of
@xml:base and the semantics of pointers are clear and should be
consistently implemented for all attributes and ids. If there's an
@xml:base, all pointers in the document should be resolved based on it.

Cheers,
Martin

On 2017-05-02 06:46 AM, Piotr Bański wrote:

> One thought is to introduce a tei.localref datatype that would be
> defined as an XML name prepended with a '#'. That could help in cases
> where one would like to create (by means of Schematron[1]) an analogy to
> the IDREF mechanism. And since the type wouldn't be defined as an URI,
> xml:base expansion wouldn't apply to it.
>
> [1] Maybe the Schematron check should even be an internal part of the
> definition of that datatype, to force document() -- except I am not so
> sure how "document()" would behave in such cases. I'd love to be
> enlightened.
>
> Musing aloud,
>   Piotr
>
> On 05/02/17 14:46, John P. McCaskey wrote:
>> @rendition has datatype teidata.pointer. Pointers can point to locations
>> either within the current document or elsewhere. They should be expanded
>> with any @xml:base attributes up the XML tree.
>>
>> But @rendition is supposed to point to an element in the tagsDecl
>> element, normally within the same document, though presumably it could
>> be the tagsDecl in some other document.
>>
>> My question: Is it really the case that a rendition pointer should honor
>> parent @xml:base attributes?
>>
>> I guess the theoretical answer is yes, but I can imagine cases where the
>> @xml:base attributes are primarily for setting image paths, .xml
>> directories, and http addresses, and the coder does not really intend
>> the @rendition attributes to point externally.
>>
>> Thoughts?
>>
>> John
>>
Reply | Threaded
Open this post in threaded view
|

Re: @xml:base with @rendition (and maybe other pointers)

John P. McCaskey-2

Is there a way, in <a class="moz-txt-link-freetext" href="xml:base">xml:base semantics, to explicitly make a pointer relative to the document instead of to the <a class="moz-txt-link-freetext" href="xml:base">xml:base active at the node? Something like “thisDocument#id”?

If so, then the good practice could be to use this for @rendition and other internal pointers. Then modification of <a class="moz-txt-link-freetext" href="xml:base">xml:base to, say, relocate images or hyperlinks, would not mess up the internal pointers. And it would allow pointers typically internal to still have external reference when needed.

John

On 5/2/2017 11:19 AM, Martin Holmes wrote:
I think the same rules should apply to all pointer types. John is right to remind us of something I've been guilty of many times over: writing pointer-handling code that doesn't think to look at @<a class="moz-txt-link-freetext" href="xml:base">xml:base. But that's my fault, not the fault of XML or TEI. I think the semantics of @<a class="moz-txt-link-freetext" href="xml:base">xml:base and the semantics of pointers are clear and should be consistently implemented for all attributes and ids. If there's an @<a class="moz-txt-link-freetext" href="xml:base">xml:base, all pointers in the document should be resolved based on it.

Cheers,
Martin

On 2017-05-02 06:46 AM, Piotr Bański wrote:
One thought is to introduce a tei.localref datatype that would be
defined as an XML name prepended with a '#'. That could help in cases
where one would like to create (by means of Schematron[1]) an analogy to
the IDREF mechanism. And since the type wouldn't be defined as an URI,
<a class="moz-txt-link-freetext" href="xml:base">xml:base expansion wouldn't apply to it.

[1] Maybe the Schematron check should even be an internal part of the
definition of that datatype, to force document() -- except I am not so
sure how "document()" would behave in such cases. I'd love to be
enlightened.

Musing aloud,
  Piotr

On 05/02/17 14:46, John P. McCaskey wrote:
@rendition has datatype teidata.pointer. Pointers can point to locations
either within the current document or elsewhere. They should be expanded
with any @<a class="moz-txt-link-freetext" href="xml:base">xml:base attributes up the XML tree.

But @rendition is supposed to point to an element in the tagsDecl
element, normally within the same document, though presumably it could
be the tagsDecl in some other document.

My question: Is it really the case that a rendition pointer should honor
parent @<a class="moz-txt-link-freetext" href="xml:base">xml:base attributes?

I guess the theoretical answer is yes, but I can imagine cases where the
@<a class="moz-txt-link-freetext" href="xml:base">xml:base attributes are primarily for setting image paths, .xml
directories, and http addresses, and the coder does not really intend
the @rendition attributes to point externally.

Thoughts?

John


Reply | Threaded
Open this post in threaded view
|

Re: @xml:base with @rendition (and maybe other pointers)

Piotr Banski
In reply to this post by Martin Holmes
Hi Martin,

So if you have a <ref> with both a @target that is resolved via xml:base
in your project, and with @rendition, will your strategy be to cancel
xml:base on this very element for the sake of @rendition and therefore
use a full URL for the @target (think about how nicely un-maintainable
it's going to be) OR will your strategy be to use some kind of
"file://.#bing" magic (<-- would that even work, sustainably?) ?

Whichever you choose, the result is going to be suboptimal. I was just
suggesting localizing this suboptimality in such a way as to make it
useful for other purposes. I for one would be quite happy to have
attributes which could only be interpreted as fragment identifiers
resolvable against the current document.

Best,

   P.


On 05/02/17 17:19, Martin Holmes wrote:

> I think the same rules should apply to all pointer types. John is
> right to remind us of something I've been guilty of many times over:
> writing pointer-handling code that doesn't think to look at @xml:base.
> But that's my fault, not the fault of XML or TEI. I think the
> semantics of @xml:base and the semantics of pointers are clear and
> should be consistently implemented for all attributes and ids. If
> there's an @xml:base, all pointers in the document should be resolved
> based on it.
>
> Cheers,
> Martin
>
> On 2017-05-02 06:46 AM, Piotr Bański wrote:
>> One thought is to introduce a tei.localref datatype that would be
>> defined as an XML name prepended with a '#'. That could help in cases
>> where one would like to create (by means of Schematron[1]) an analogy to
>> the IDREF mechanism. And since the type wouldn't be defined as an URI,
>> xml:base expansion wouldn't apply to it.
>>
>> [1] Maybe the Schematron check should even be an internal part of the
>> definition of that datatype, to force document() -- except I am not so
>> sure how "document()" would behave in such cases. I'd love to be
>> enlightened.
>>
>> Musing aloud,
>>   Piotr
>>
>> On 05/02/17 14:46, John P. McCaskey wrote:
>>> @rendition has datatype teidata.pointer. Pointers can point to
>>> locations
>>> either within the current document or elsewhere. They should be
>>> expanded
>>> with any @xml:base attributes up the XML tree.
>>>
>>> But @rendition is supposed to point to an element in the tagsDecl
>>> element, normally within the same document, though presumably it could
>>> be the tagsDecl in some other document.
>>>
>>> My question: Is it really the case that a rendition pointer should
>>> honor
>>> parent @xml:base attributes?
>>>
>>> I guess the theoretical answer is yes, but I can imagine cases where
>>> the
>>> @xml:base attributes are primarily for setting image paths, .xml
>>> directories, and http addresses, and the coder does not really intend
>>> the @rendition attributes to point externally.
>>>
>>> Thoughts?
>>>
>>> John
>>>
>
Reply | Threaded
Open this post in threaded view
|

Re: @xml:base with @rendition (and maybe other pointers)

Martin Holmes
HI Piotr,

I must admit I don't really understand the problem here. If there's
efficiency to be gained from using @xml:base (shorter pointers in many
pointing attributes), but it causes other pointers (such as @rendition)
to be more difficult to handle, I would use a private URI scheme and a
<prefixDef> to handle it.

One unanswered question might be whether the dereferencing process in a
prefixDef is supposed to take account of @xml:base, though...

Cheers,
Martin

On 2017-05-02 11:10 AM, Piotr Banski wrote:

> Hi Martin,
>
> So if you have a <ref> with both a @target that is resolved via xml:base
> in your project, and with @rendition, will your strategy be to cancel
> xml:base on this very element for the sake of @rendition and therefore
> use a full URL for the @target (think about how nicely un-maintainable
> it's going to be) OR will your strategy be to use some kind of
> "file://.#bing" magic (<-- would that even work, sustainably?) ?
>
> Whichever you choose, the result is going to be suboptimal. I was just
> suggesting localizing this suboptimality in such a way as to make it
> useful for other purposes. I for one would be quite happy to have
> attributes which could only be interpreted as fragment identifiers
> resolvable against the current document.
>
> Best,
>
>   P.
>
>
> On 05/02/17 17:19, Martin Holmes wrote:
>> I think the same rules should apply to all pointer types. John is
>> right to remind us of something I've been guilty of many times over:
>> writing pointer-handling code that doesn't think to look at @xml:base.
>> But that's my fault, not the fault of XML or TEI. I think the
>> semantics of @xml:base and the semantics of pointers are clear and
>> should be consistently implemented for all attributes and ids. If
>> there's an @xml:base, all pointers in the document should be resolved
>> based on it.
>>
>> Cheers,
>> Martin
>>
>> On 2017-05-02 06:46 AM, Piotr Bański wrote:
>>> One thought is to introduce a tei.localref datatype that would be
>>> defined as an XML name prepended with a '#'. That could help in cases
>>> where one would like to create (by means of Schematron[1]) an analogy to
>>> the IDREF mechanism. And since the type wouldn't be defined as an URI,
>>> xml:base expansion wouldn't apply to it.
>>>
>>> [1] Maybe the Schematron check should even be an internal part of the
>>> definition of that datatype, to force document() -- except I am not so
>>> sure how "document()" would behave in such cases. I'd love to be
>>> enlightened.
>>>
>>> Musing aloud,
>>>   Piotr
>>>
>>> On 05/02/17 14:46, John P. McCaskey wrote:
>>>> @rendition has datatype teidata.pointer. Pointers can point to
>>>> locations
>>>> either within the current document or elsewhere. They should be
>>>> expanded
>>>> with any @xml:base attributes up the XML tree.
>>>>
>>>> But @rendition is supposed to point to an element in the tagsDecl
>>>> element, normally within the same document, though presumably it could
>>>> be the tagsDecl in some other document.
>>>>
>>>> My question: Is it really the case that a rendition pointer should
>>>> honor
>>>> parent @xml:base attributes?
>>>>
>>>> I guess the theoretical answer is yes, but I can imagine cases where
>>>> the
>>>> @xml:base attributes are primarily for setting image paths, .xml
>>>> directories, and http addresses, and the coder does not really intend
>>>> the @rendition attributes to point externally.
>>>>
>>>> Thoughts?
>>>>
>>>> John
>>>>
>>
Reply | Threaded
Open this post in threaded view
|

Re: @xml:base with @rendition (and maybe other pointers)

Hugh Cayless-2
Unless I'm just confused, a fragment identifier (#whatever) won't, at least in HTTP(S)-land, result in a new dereference, regardless of the value of @xml:base. They exclusively refer to parts of the same document, so there's no possibility for confusion. @xml:base only applies to any relative URIs in your document.

In any case, I'm firmly of the opinion that @xml:base is one of those too-clever-by-half ideas that should be avoided like the plague.

If I'm wrong, I'd be happy to be educated!

All the best,
Hugh

On Tue, May 2, 2017 at 2:19 PM, Martin Holmes <[hidden email]> wrote:
HI Piotr,

I must admit I don't really understand the problem here. If there's efficiency to be gained from using @xml:base (shorter pointers in many pointing attributes), but it causes other pointers (such as @rendition) to be more difficult to handle, I would use a private URI scheme and a <prefixDef> to handle it.

One unanswered question might be whether the dereferencing process in a prefixDef is supposed to take account of @xml:base, though...

Cheers,
Martin


On 2017-05-02 11:10 AM, Piotr Banski wrote:
Hi Martin,

So if you have a <ref> with both a @target that is resolved via xml:base
in your project, and with @rendition, will your strategy be to cancel
xml:base on this very element for the sake of @rendition and therefore
use a full URL for the @target (think about how nicely un-maintainable
it's going to be) OR will your strategy be to use some kind of
"file://.#bing" magic (<-- would that even work, sustainably?) ?

Whichever you choose, the result is going to be suboptimal. I was just
suggesting localizing this suboptimality in such a way as to make it
useful for other purposes. I for one would be quite happy to have
attributes which could only be interpreted as fragment identifiers
resolvable against the current document.

Best,

  P.


On 05/02/17 17:19, Martin Holmes wrote:
I think the same rules should apply to all pointer types. John is
right to remind us of something I've been guilty of many times over:
writing pointer-handling code that doesn't think to look at @xml:base.
But that's my fault, not the fault of XML or TEI. I think the
semantics of @xml:base and the semantics of pointers are clear and
should be consistently implemented for all attributes and ids. If
there's an @xml:base, all pointers in the document should be resolved
based on it.

Cheers,
Martin

On 2017-05-02 06:46 AM, Piotr Bański wrote:
One thought is to introduce a tei.localref datatype that would be
defined as an XML name prepended with a '#'. That could help in cases
where one would like to create (by means of Schematron[1]) an analogy to
the IDREF mechanism. And since the type wouldn't be defined as an URI,
xml:base expansion wouldn't apply to it.

[1] Maybe the Schematron check should even be an internal part of the
definition of that datatype, to force document() -- except I am not so
sure how "document()" would behave in such cases. I'd love to be
enlightened.

Musing aloud,
  Piotr

On 05/02/17 14:46, John P. McCaskey wrote:
@rendition has datatype teidata.pointer. Pointers can point to
locations
either within the current document or elsewhere. They should be
expanded
with any @xml:base attributes up the XML tree.

But @rendition is supposed to point to an element in the tagsDecl
element, normally within the same document, though presumably it could
be the tagsDecl in some other document.

My question: Is it really the case that a rendition pointer should
honor
parent @xml:base attributes?

I guess the theoretical answer is yes, but I can imagine cases where
the
@xml:base attributes are primarily for setting image paths, .xml
directories, and http addresses, and the coder does not really intend
the @rendition attributes to point externally.

Thoughts?

John



Reply | Threaded
Open this post in threaded view
|

Re: @xml:base with @rendition (and maybe other pointers)

Piotr Banski
In reply to this post by John P. McCaskey-2

You can either nullify xml:base locally as needed (when you decide on using rendition) or make the URL complete, either via the file system or via your web server, but neither of these would qualify as "good practice", IMO.

In your specific case, I think defaulting @rendition could help, if you are able to default it on the elements in question. It doesn't really close the can of worms, because this is not a systemic solution for when you have two attributes on a single element in a situation when one of them should be resolved via xml:base and the other should not. But it might be sufficient for your purposes. I think the defaulting should be described in the documentation of @rendition, Syd Bauman has recently announced a new approach to it but I forget where :-)

Good luck,

  Piotr

On 05/02/17 17:30, John P. McCaskey wrote:

Is there a way, in <a moz-do-not-send="true" class="moz-txt-link-freetext" href="xml:base">xml:base semantics, to explicitly make a pointer relative to the document instead of to the <a moz-do-not-send="true" class="moz-txt-link-freetext" href="xml:base">xml:base active at the node? Something like “thisDocument#id”?

If so, then the good practice could be to use this for @rendition and other internal pointers. Then modification of <a moz-do-not-send="true" class="moz-txt-link-freetext" href="xml:base">xml:base to, say, relocate images or hyperlinks, would not mess up the internal pointers. And it would allow pointers typically internal to still have external reference when needed.

John

On 5/2/2017 11:19 AM, Martin Holmes wrote:
I think the same rules should apply to all pointer types. John is right to remind us of something I've been guilty of many times over: writing pointer-handling code that doesn't think to look at @<a moz-do-not-send="true" class="moz-txt-link-freetext" href="xml:base">xml:base. But that's my fault, not the fault of XML or TEI. I think the semantics of @<a moz-do-not-send="true" class="moz-txt-link-freetext" href="xml:base">xml:base and the semantics of pointers are clear and should be consistently implemented for all attributes and ids. If there's an @<a moz-do-not-send="true" class="moz-txt-link-freetext" href="xml:base">xml:base, all pointers in the document should be resolved based on it.

Cheers,
Martin

On 2017-05-02 06:46 AM, Piotr Bański wrote:
One thought is to introduce a tei.localref datatype that would be
defined as an XML name prepended with a '#'. That could help in cases
where one would like to create (by means of Schematron[1]) an analogy to
the IDREF mechanism. And since the type wouldn't be defined as an URI,
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="xml:base">xml:base expansion wouldn't apply to it.

[1] Maybe the Schematron check should even be an internal part of the
definition of that datatype, to force document() -- except I am not so
sure how "document()" would behave in such cases. I'd love to be
enlightened.

Musing aloud,
  Piotr

On 05/02/17 14:46, John P. McCaskey wrote:
@rendition has datatype teidata.pointer. Pointers can point to locations
either within the current document or elsewhere. They should be expanded
with any @<a moz-do-not-send="true" class="moz-txt-link-freetext" href="xml:base">xml:base attributes up the XML tree.

But @rendition is supposed to point to an element in the tagsDecl
element, normally within the same document, though presumably it could
be the tagsDecl in some other document.

My question: Is it really the case that a rendition pointer should honor
parent @<a moz-do-not-send="true" class="moz-txt-link-freetext" href="xml:base">xml:base attributes?

I guess the theoretical answer is yes, but I can imagine cases where the
@<a moz-do-not-send="true" class="moz-txt-link-freetext" href="xml:base">xml:base attributes are primarily for setting image paths, .xml
directories, and http addresses, and the coder does not really intend
the @rendition attributes to point externally.

Thoughts?

John



Reply | Threaded
Open this post in threaded view
|

Re: @xml:base with @rendition (and maybe other pointers)

John P. McCaskey-2
In reply to this post by Hugh Cayless-2
Is this correct? Do identifiers refer only to the current document? 

I assumed you could have a dictionary page, www.somedictionary.com/a.html, set using xml:base, and then have @target values in a <ref> of #apple, #apricot, and #avocado. 

Is that not right? 

(Sent from John's iPhone 6.)

On May 2, 2017, at 2:36 PM, Hugh Cayless <[hidden email]> wrote:

Unless I'm just confused, a fragment identifier (#whatever) won't, at least in HTTP(S)-land, result in a new dereference, regardless of the value of @xml:base. They exclusively refer to parts of the same document, so there's no possibility for confusion. @xml:base only applies to any relative URIs in your document.

In any case, I'm firmly of the opinion that @xml:base is one of those too-clever-by-half ideas that should be avoided like the plague.

If I'm wrong, I'd be happy to be educated!

All the best,
Hugh

On Tue, May 2, 2017 at 2:19 PM, Martin Holmes <[hidden email]> wrote:
HI Piotr,

I must admit I don't really understand the problem here. If there's efficiency to be gained from using @xml:base (shorter pointers in many pointing attributes), but it causes other pointers (such as @rendition) to be more difficult to handle, I would use a private URI scheme and a <prefixDef> to handle it.

One unanswered question might be whether the dereferencing process in a prefixDef is supposed to take account of @xml:base, though...

Cheers,
Martin


On 2017-05-02 11:10 AM, Piotr Banski wrote:
Hi Martin,

So if you have a <ref> with both a @target that is resolved via xml:base
in your project, and with @rendition, will your strategy be to cancel
xml:base on this very element for the sake of @rendition and therefore
use a full URL for the @target (think about how nicely un-maintainable
it's going to be) OR will your strategy be to use some kind of
"file://.#bing" magic (<-- would that even work, sustainably?) ?

Whichever you choose, the result is going to be suboptimal. I was just
suggesting localizing this suboptimality in such a way as to make it
useful for other purposes. I for one would be quite happy to have
attributes which could only be interpreted as fragment identifiers
resolvable against the current document.

Best,

  P.


On 05/02/17 17:19, Martin Holmes wrote:
I think the same rules should apply to all pointer types. John is
right to remind us of something I've been guilty of many times over:
writing pointer-handling code that doesn't think to look at @xml:base.
But that's my fault, not the fault of XML or TEI. I think the
semantics of @xml:base and the semantics of pointers are clear and
should be consistently implemented for all attributes and ids. If
there's an @xml:base, all pointers in the document should be resolved
based on it.

Cheers,
Martin

On 2017-05-02 06:46 AM, Piotr Bański wrote:
One thought is to introduce a tei.localref datatype that would be
defined as an XML name prepended with a '#'. That could help in cases
where one would like to create (by means of Schematron[1]) an analogy to
the IDREF mechanism. And since the type wouldn't be defined as an URI,
xml:base expansion wouldn't apply to it.

[1] Maybe the Schematron check should even be an internal part of the
definition of that datatype, to force document() -- except I am not so
sure how "document()" would behave in such cases. I'd love to be
enlightened.

Musing aloud,
  Piotr

On 05/02/17 14:46, John P. McCaskey wrote:
@rendition has datatype teidata.pointer. Pointers can point to
locations
either within the current document or elsewhere. They should be
expanded
with any @xml:base attributes up the XML tree.

But @rendition is supposed to point to an element in the tagsDecl
element, normally within the same document, though presumably it could
be the tagsDecl in some other document.

My question: Is it really the case that a rendition pointer should
honor
parent @xml:base attributes?

I guess the theoretical answer is yes, but I can imagine cases where
the
@xml:base attributes are primarily for setting image paths, .xml
directories, and http addresses, and the coder does not really intend
the @rendition attributes to point externally.

Thoughts?

John



Reply | Threaded
Open this post in threaded view
|

Re: @xml:base with @rendition (and maybe other pointers)

Martin Holmes
In reply to this post by Hugh Cayless-2
I've always assumed that local pointers (#myElement) are just relative
URIs, and that they should be dereffed taking account of @xml:base -- so:

<ref xml:base="http://www.tei-c.org/" target="#main">

expands to:

http://www.tei-c.org/#main

I can't find anything here:

<https://www.w3.org/TR/2001/REC-xmlbase-20010627/>

which to my (admittedly limited) mind appears to say otherwise. And
thinking about it, if I wanted to reference a document fragment
identifier in a document which was the root of @xml:base, isn't this how
it would be done? It would be weird to have to do this:

<TEI xmlns="http://www.tei-c.org" xml:base="http://www.tei-c.org/">

[...]

<ref target="http://www.tei-c.org/#main">

wouldn't it?

Cheers,
Martin

On 2017-05-02 11:36 AM, Hugh Cayless wrote:

> Unless I'm just confused, a fragment identifier (#whatever) won't, at
> least in HTTP(S)-land, result in a new dereference, regardless of the
> value of @xml:base. They exclusively refer to parts of the same
> document, so there's no possibility for confusion. @xml:base only
> applies to any relative URIs in your document.
>
> In any case, I'm firmly of the opinion that @xml:base is one of those
> too-clever-by-half ideas that should be avoided like the plague.
>
> If I'm wrong, I'd be happy to be educated!
>
> All the best,
> Hugh
>
> On Tue, May 2, 2017 at 2:19 PM, Martin Holmes <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     HI Piotr,
>
>     I must admit I don't really understand the problem here. If there's
>     efficiency to be gained from using @xml:base (shorter pointers in
>     many pointing attributes), but it causes other pointers (such as
>     @rendition) to be more difficult to handle, I would use a private
>     URI scheme and a <prefixDef> to handle it.
>
>     One unanswered question might be whether the dereferencing process
>     in a prefixDef is supposed to take account of @xml:base, though...
>
>     Cheers,
>     Martin
>
>
>     On 2017-05-02 11:10 AM, Piotr Banski wrote:
>
>         Hi Martin,
>
>         So if you have a <ref> with both a @target that is resolved via
>         xml:base
>         in your project, and with @rendition, will your strategy be to
>         cancel
>         xml:base on this very element for the sake of @rendition and
>         therefore
>         use a full URL for the @target (think about how nicely
>         un-maintainable
>         it's going to be) OR will your strategy be to use some kind of
>         "file://.#bing" magic (<-- would that even work, sustainably?) ?
>
>         Whichever you choose, the result is going to be suboptimal. I
>         was just
>         suggesting localizing this suboptimality in such a way as to make it
>         useful for other purposes. I for one would be quite happy to have
>         attributes which could only be interpreted as fragment identifiers
>         resolvable against the current document.
>
>         Best,
>
>           P.
>
>
>         On 05/02/17 17:19, Martin Holmes wrote:
>
>             I think the same rules should apply to all pointer types.
>             John is
>             right to remind us of something I've been guilty of many
>             times over:
>             writing pointer-handling code that doesn't think to look at
>             @xml:base.
>             But that's my fault, not the fault of XML or TEI. I think the
>             semantics of @xml:base and the semantics of pointers are
>             clear and
>             should be consistently implemented for all attributes and
>             ids. If
>             there's an @xml:base, all pointers in the document should be
>             resolved
>             based on it.
>
>             Cheers,
>             Martin
>
>             On 2017-05-02 06:46 AM, Piotr Bański wrote:
>
>                 One thought is to introduce a tei.localref datatype that
>                 would be
>                 defined as an XML name prepended with a '#'. That could
>                 help in cases
>                 where one would like to create (by means of
>                 Schematron[1]) an analogy to
>                 the IDREF mechanism. And since the type wouldn't be
>                 defined as an URI,
>                 xml:base expansion wouldn't apply to it.
>
>                 [1] Maybe the Schematron check should even be an
>                 internal part of the
>                 definition of that datatype, to force document() --
>                 except I am not so
>                 sure how "document()" would behave in such cases. I'd
>                 love to be
>                 enlightened.
>
>                 Musing aloud,
>                   Piotr
>
>                 On 05/02/17 14:46, John P. McCaskey wrote:
>
>                     @rendition has datatype teidata.pointer. Pointers
>                     can point to
>                     locations
>                     either within the current document or elsewhere.
>                     They should be
>                     expanded
>                     with any @xml:base attributes up the XML tree.
>
>                     But @rendition is supposed to point to an element in
>                     the tagsDecl
>                     element, normally within the same document, though
>                     presumably it could
>                     be the tagsDecl in some other document.
>
>                     My question: Is it really the case that a rendition
>                     pointer should
>                     honor
>                     parent @xml:base attributes?
>
>                     I guess the theoretical answer is yes, but I can
>                     imagine cases where
>                     the
>                     @xml:base attributes are primarily for setting image
>                     paths, .xml
>                     directories, and http addresses, and the coder does
>                     not really intend
>                     the @rendition attributes to point externally.
>
>                     Thoughts?
>
>                     John
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: @xml:base with @rendition (and maybe other pointers)

Syd Bauman-10
In reply to this post by Martin Holmes
Martin has taken the words right out of my mouth:
> One unanswered question might be whether the dereferencing process
> in a prefixDef is supposed to take account of @xml:base, though...

But I also have to admit, I'm not 100% sure how
| <note xml:base="http://www.example.edu/SydNotes.xml" target="#silly"/>
is supposed to be dereferenced. I have always thought it meant
the element at http://www.example.edu/SydNotes.xml#silly. But RFC
3986 "Uniform Resource Identifier (URI): Generic Syntax" says
|  When a same-document reference is dereferenced for a retrieval
|  action, the target of that reference is defined to be within the
|  same entity (representation, document, or message) as the
|  reference; therefore, a dereference should not result in a new
|  retrieval action.
which confuses me.


All this leads me to prefer <prefixDef> over @xml:base.
Reply | Threaded
Open this post in threaded view
|

Re: @xml:base with @rendition (and maybe other pointers)

Hugh Cayless-2
Yes, hence my view of @xml:base as unintentionally evil. My reading of the section of RFC 3986 you quote is that the dereferencing of a fragment id should not result in fetching a new document (as it might if @xml:base was different from the current document). Moreover, in the same document, "#" is defined, along with "", as a same-document reference, again regardless of the value of @xml:base, so I think the implication is that fragment identifiers always refer to the current document.

All that said, there seems to be a fair amount of confusion out there from my quick Googling around, leading to inconsistent implementations. Also, the resolution of fragment IDs is dependent on the media type, so I suppose in theory we get to pick what it does :-). I vote fragment ids ignore @xml:base!

If this is true, we really ought to say something about it in the Guidelines so that implementors don't go off the rails.

On Tue, May 2, 2017 at 2:52 PM, Syd Bauman <[hidden email]> wrote:
Martin has taken the words right out of my mouth:
> One unanswered question might be whether the dereferencing process
> in a prefixDef is supposed to take account of @xml:base, though...

But I also have to admit, I'm not 100% sure how
| <note xml:base="http://www.example.edu/SydNotes.xml" target="#silly"/>
is supposed to be dereferenced. I have always thought it meant
the element at http://www.example.edu/SydNotes.xml#silly. But RFC
3986 "Uniform Resource Identifier (URI): Generic Syntax" says
|  When a same-document reference is dereferenced for a retrieval
|  action, the target of that reference is defined to be within the
|  same entity (representation, document, or message) as the
|  reference; therefore, a dereference should not result in a new
|  retrieval action.
which confuses me.


All this leads me to prefer <prefixDef> over @xml:base.

Reply | Threaded
Open this post in threaded view
|

Re: @xml:base with @rendition (and maybe other pointers)

John P. McCaskey-2
In reply to this post by Syd Bauman-10
On 5/2/2017 2:52 PM, Syd Bauman wrote:
Martin has taken the words right out of my mouth:
One unanswered question might be whether the dereferencing process
in a prefixDef is supposed to take account of @<a class="moz-txt-link-freetext" href="xml:base">xml:base, though...
Doesn’t this (from here) answer that question?
The abbreviated pointer may be dereferenced to produce either an absolute or a relative URI reference. In the latter case it is combined with the value of <a class="moz-txt-link-freetext" href="xml:base">xml:base in force at the place where the pointing attribute occurs to form an absolute URI in the usual manner as prescribed by XML Base.
If you are willing to say some pointers (such as those with prefixDef entries) should not use <a class="moz-txt-link-freetext" href="xml:base">xml:base, why not feel liberated to do so for pointers that are just fragment IDs or specifically named pointers such as @rendition?

-- John
Reply | Threaded
Open this post in threaded view
|

Re: @xml:base with @rendition (and maybe other pointers)

Martin Holmes
In reply to this post by Syd Bauman-10
On 2017-05-02 11:52 AM, Syd Bauman wrote:
> Martin has taken the words right out of my mouth:
>> One unanswered question might be whether the dereferencing process
>> in a prefixDef is supposed to take account of @xml:base, though...

I've raised an issue for that specific point:

<https://github.com/TEIC/TEI/issues/1637>

Cheers,
Martin

> But I also have to admit, I'm not 100% sure how
> | <note xml:base="http://www.example.edu/SydNotes.xml" target="#silly"/>
> is supposed to be dereferenced. I have always thought it meant
> the element at http://www.example.edu/SydNotes.xml#silly. But RFC
> 3986 "Uniform Resource Identifier (URI): Generic Syntax" says
> |  When a same-document reference is dereferenced for a retrieval
> |  action, the target of that reference is defined to be within the
> |  same entity (representation, document, or message) as the
> |  reference; therefore, a dereference should not result in a new
> |  retrieval action.
> which confuses me.
>
>
> All this leads me to prefer <prefixDef> over @xml:base.
>
Reply | Threaded
Open this post in threaded view
|

Re: @xml:base with @rendition (and maybe other pointers)

John P. McCaskey-2
In reply to this post by Hugh Cayless-2

On 5/2/2017 3:30 PM, Hugh Cayless wrote:

I vote fragment ids ignore @<a class="moz-txt-link-freetext" href="xml:base">xml:base!

I think that’s a risky and and unnatural limitation. @<a class="moz-txt-link-freetext" href="xml:base=">xml:base="http://www.dictionary.html/" followed by @<a class="moz-txt-link-freetext" href="xml:base=">xml:base="a.html" followed by @target="#apple" seems a good way to point to "http://www.dictionary.com/a.html#apple".

I’d prefer saying some named attributes (e.g., @rendition) ignore <a class="moz-txt-link-freetext" href="xml:base—which">xml:base—which puts us back to

Piotr’s tei.localref.

But then there is some value is centralizing a project’s rendition mappings in one external file.

Hmm . . .




Yes, hence my view of @<a class="moz-txt-link-freetext" href="xml:base">xml:base as unintentionally evil. My reading of the section of RFC 3986 you quote is that the dereferencing of a fragment id should not result in fetching a new document (as it might if @<a class="moz-txt-link-freetext" href="xml:base">xml:base was different from the current document). Moreover, in the same document, "#" is defined, along with "", as a same-document reference, again regardless of the value of @<a class="moz-txt-link-freetext" href="xml:base">xml:base, so I think the implication is that fragment identifiers always refer to the current document.

All that said, there seems to be a fair amount of confusion out there from my quick Googling around, leading to inconsistent implementations. Also, the resolution of fragment IDs is dependent on the media type, so I suppose in theory we get to pick what it does :-). I vote fragment ids ignore @<a class="moz-txt-link-freetext" href="xml:base">xml:base!

If this is true, we really ought to say something about it in the Guidelines so that implementors don't go off the rails.

On Tue, May 2, 2017 at 2:52 PM, Syd Bauman <[hidden email]> wrote:
Martin has taken the words right out of my mouth:
> One unanswered question might be whether the dereferencing process
> in a prefixDef is supposed to take account of @<a class="moz-txt-link-freetext" href="xml:base">xml:base, though...

But I also have to admit, I'm not 100% sure how
| <note <a class="moz-txt-link-freetext" href="xml:base=">xml:base="http://www.example.edu/SydNotes.xml" target="#silly"/>
is supposed to be dereferenced. I have always thought it meant
the element at http://www.example.edu/SydNotes.xml#silly. But RFC
3986 "Uniform Resource Identifier (URI): Generic Syntax" says
|  When a same-document reference is dereferenced for a retrieval
|  action, the target of that reference is defined to be within the
|  same entity (representation, document, or message) as the
|  reference; therefore, a dereference should not result in a new
|  retrieval action.
which confuses me.


All this leads me to prefer <prefixDef> over @<a class="moz-txt-link-freetext" href="xml:base">xml:base.


Reply | Threaded
Open this post in threaded view
|

Re: @xml:base with @rendition (and maybe other pointers)

Hugh Cayless-2
In reply to this post by John P. McCaskey-2
I think John is quite right about the question of URIs using defined prefixes. It depends whether the prefix results in an absolute URI or not.

I think fragment identifiers are a different question, but that a) they should be understood to refer to the current document regardless of @xml:base and b) since we're in charge of the TEI media type, we get to decide, and should choose a).

To treat @rendition differently would in my opinion require that we change its data type.

On Tue, May 2, 2017 at 3:42 PM, John P. McCaskey <[hidden email]> wrote:
On 5/2/2017 2:52 PM, Syd Bauman wrote:
Martin has taken the words right out of my mouth:
One unanswered question might be whether the dereferencing process
in a prefixDef is supposed to take account of @xml:base, though...
Doesn’t this (from here) answer that question?
The abbreviated pointer may be dereferenced to produce either an absolute or a relative URI reference. In the latter case it is combined with the value of xml:base in force at the place where the pointing attribute occurs to form an absolute URI in the usual manner as prescribed by XML Base.
If you are willing to say some pointers (such as those with prefixDef entries) should not use xml:base, why not feel liberated to do so for pointers that are just fragment IDs or specifically named pointers such as @rendition?

-- John

Reply | Threaded
Open this post in threaded view
|

Re: @xml:base with @rendition (and maybe other pointers)

Martin Holmes
In reply to this post by John P. McCaskey-2
On 2017-05-02 12:42 PM, John P. McCaskey wrote:

> On 5/2/2017 2:52 PM, Syd Bauman wrote:
>> Martin has taken the words right out of my mouth:
>>> One unanswered question might be whether the dereferencing process
>>> in a prefixDef is supposed to take account of @xml:base, though...
> Doesn’t this(from here
> <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-prefixDef.html>) answer
> that question?
>
>     The abbreviated pointer may be dereferenced to produce either an
>     absolute or a relative URI reference. In the latter case it is
>     combined with the value of xml:base in force at the place where the
>     pointing attribute occurs to form an absolute URI in the usual
>     manner as prescribed by XML Base <http://www.w3.org/TR/xmlbase/>.

I had completely forgotten that the prefixDef note was there.

Doh. I've closed my silly ticket.

Cheers,
Martin



>
> If you are willing to say some pointers (such as those with prefixDef
> entries) should not use xml:base, why not feel liberated to do so for
> pointers that are just fragment IDs or specifically named pointers such
> as @rendition?
>
> -- John
Reply | Threaded
Open this post in threaded view
|

Re: @xml:base with @rendition (and maybe other pointers)

Hugh Cayless-2
In reply to this post by John P. McCaskey-2
I think it's a perfectly safe, rational, and intuitive one. And, moreover, one that follows https://tools.ietf.org/html/rfc3986#page-27 section 4.4:

   When a URI reference refers to a URI that is, aside from its fragment
   component (if any), identical to the base URI (Section 5.1), that
   reference is called a "same-document" reference.  The most frequent
   examples of same-document references are relative references that are
   empty or include only the number sign ("#") separator followed by a
   fragment identifier.

On Tue, May 2, 2017 at 3:55 PM, John P. McCaskey <[hidden email]> wrote:

On 5/2/2017 3:30 PM, Hugh Cayless wrote:

I vote fragment ids ignore @xml:base!

I think that’s a risky and and unnatural limitation. @xml:base="http://www.dictionary.html/" followed by @xml:base="a.html" followed by @target="#apple" seems a good way to point to "http://www.dictionary.com/a.html#apple".

I’d prefer saying some named attributes (e.g., @rendition) ignore xml:base—which puts us back to

Piotr’s tei.localref.

But then there is some value is centralizing a project’s rendition mappings in one external file.

Hmm . . .




Yes, hence my view of @xml:base as unintentionally evil. My reading of the section of RFC 3986 you quote is that the dereferencing of a fragment id should not result in fetching a new document (as it might if @xml:base was different from the current document). Moreover, in the same document, "#" is defined, along with "", as a same-document reference, again regardless of the value of @xml:base, so I think the implication is that fragment identifiers always refer to the current document.

All that said, there seems to be a fair amount of confusion out there from my quick Googling around, leading to inconsistent implementations. Also, the resolution of fragment IDs is dependent on the media type, so I suppose in theory we get to pick what it does :-). I vote fragment ids ignore @xml:base!

If this is true, we really ought to say something about it in the Guidelines so that implementors don't go off the rails.

On Tue, May 2, 2017 at 2:52 PM, Syd Bauman <[hidden email]> wrote:
Martin has taken the words right out of my mouth:
> One unanswered question might be whether the dereferencing process
> in a prefixDef is supposed to take account of @xml:base, though...

But I also have to admit, I'm not 100% sure how
| <note xml:base="http://www.example.edu/SydNotes.xml" target="#silly"/>
is supposed to be dereferenced. I have always thought it meant
the element at http://www.example.edu/SydNotes.xml#silly. But RFC
3986 "Uniform Resource Identifier (URI): Generic Syntax" says
|  When a same-document reference is dereferenced for a retrieval
|  action, the target of that reference is defined to be within the
|  same entity (representation, document, or message) as the
|  reference; therefore, a dereference should not result in a new
|  retrieval action.
which confuses me.


All this leads me to prefer <prefixDef> over @xml:base.



Reply | Threaded
Open this post in threaded view
|

Re: @xml:base with @rendition (and maybe other pointers)

John P. McCaskey-2

In XML, isn’t “base URI“ something specific to an element, not to the document?

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.

Doesn’t this paragraph say fragment IDs should honor the complete <a class="moz-txt-link-freetext" href="xml:base">xml:base value in effect for the attribute’s element?

John


On 5/2/2017 4:07 PM, Hugh Cayless wrote:
I think it's a perfectly safe, rational, and intuitive one. And, moreover, one that follows https://tools.ietf.org/html/rfc3986#page-27 section 4.4:

   When a URI reference refers to a URI that is, aside from its fragment
   component (if any), identical to the base URI (Section 5.1), that
   reference is called a "same-document" reference.  The most frequent
   examples of same-document references are relative references that are
   empty or include only the number sign ("#") separator followed by a
   fragment identifier.

On Tue, May 2, 2017 at 3:55 PM, John P. McCaskey <[hidden email]> wrote:

On 5/2/2017 3:30 PM, Hugh Cayless wrote:

I vote fragment ids ignore @xml:base!

I think that’s a risky and and unnatural limitation. @xml:base="http://www.dictionary.html/" followed by @xml:base="a.html" followed by @target="#apple" seems a good way to point to "http://www.dictionary.com/a.html#apple".

I’d prefer saying some named attributes (e.g., @rendition) ignore xml:base—which puts us back to

Piotr’s tei.localref.

But then there is some value is centralizing a project’s rendition mappings in one external file.

Hmm . . .




Yes, hence my view of @xml:base as unintentionally evil. My reading of the section of RFC 3986 you quote is that the dereferencing of a fragment id should not result in fetching a new document (as it might if @xml:base was different from the current document). Moreover, in the same document, "#" is defined, along with "", as a same-document reference, again regardless of the value of @xml:base, so I think the implication is that fragment identifiers always refer to the current document.

All that said, there seems to be a fair amount of confusion out there from my quick Googling around, leading to inconsistent implementations. Also, the resolution of fragment IDs is dependent on the media type, so I suppose in theory we get to pick what it does :-). I vote fragment ids ignore @xml:base!

If this is true, we really ought to say something about it in the Guidelines so that implementors don't go off the rails.

On Tue, May 2, 2017 at 2:52 PM, Syd Bauman <[hidden email]> wrote:
Martin has taken the words right out of my mouth:
> One unanswered question might be whether the dereferencing process
> in a prefixDef is supposed to take account of @xml:base, though...

But I also have to admit, I'm not 100% sure how
| <note xml:base="http://www.example.edu/SydNotes.xml" target="#silly"/>
is supposed to be dereferenced. I have always thought it meant
the element at http://www.example.edu/SydNotes.xml#silly. But RFC
3986 "Uniform Resource Identifier (URI): Generic Syntax" says
|  When a same-document reference is dereferenced for a retrieval
|  action, the target of that reference is defined to be within the
|  same entity (representation, document, or message) as the
|  reference; therefore, a dereference should not result in a new
|  retrieval action.
which confuses me.


All this leads me to prefer <prefixDef> over @xml:base.




Reply | Threaded
Open this post in threaded view
|

Re: @xml:base with @rendition (and maybe other pointers)

Syd Bauman-10
Hugh --

Where does it say the interpretation of a fragment ID *with respect
to its @xml:base* depends on the media type?

John --

Yes, I think a base URI is specific to an element (which might be the
whole document, might not).

Yes, I think the quoted passage is saying that a fragment ID points
to the same document as the base URI in effect.

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.

> In XML, isn’t “base URI“ something specific to an element, not to
> the document?
>
> 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.
>
> Doesn’t this paragraph <https://www.w3.org/TR/xmlbase/#matching>
> say fragment IDs should honor the complete xml:base value in effect
> for the attribute’s element?
1234