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

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 <[email protected]
> <mailto:[email protected]>> 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
>
>
>