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

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
>>>>
>>