In view of the discussion on why @xml:lang is unsuitable in stand-off contexts, I suggest that we introduce @refLang (name suggestion by Conal Tuohy), modeled on HTML's @hreflang , and add it to att.pointing, to be conditioned by the presence of @target.
(make sure to read on, this one just sets the context)
This is meant for cases such as <ptr @target="URI" @refLang="BCP47-value"/>
Content: data.language. Suggested semantics: @refLang identifies the language of the content of elements/documents identified by the URI.
Suggested assertion to go into the definition of the attribute, roughly:
<sch:assert test="count(@target)">@refLang can only be used if @target is specified.</sch:assert>
(this assumes that @target="" is caught elsewhere)
* can @xml:lang be used in such contexts instead, given that what is being identified is/may be virtual content of the containing element or its parent? (assumed answer: no)
* should att.global.linking be affected as well?
* should the remote character set be definable as well? and if so, how?
* do we want to bother about the language of remote attributes (suggested answer, in view of the short-sighted part of the definition of @xml:lang, and the TEI's strategy to avoid language in attributes: NO)
* what should be done if the *script* of remote *attributes* should be thus identified (not just the language)? (suggested answer: the same as in the case of mismatches between the script set by some @xml:lang and the script of attributes accompanying that @xml:lang; in other words: this is a more general problem that needs to be solved separately)