[tei-council] targetLang in att.pointing and schemaSpec

[Piotr Bański]

I wasn't saying "let's change the old one" -- the option of leaving
both, by analogy to overriding @type, seems acceptable.

As for whether "targetLang" is great for referring to tags and attribute
names, well, my point is that the name doesn't suggest anything like
that to someone who isn't simply used to it. It could just as well be
used to refer to the language of documentation or whatever else, since
"target" in this case means nearly "anything I tell you this should
mean, with some pointing/directionality implied". This meaning is
appropriate for half the attributes, including many new guys.

I'm not pressing in any direction, though if I were forced to take a
stand, I'd probably vote on "keep both", because I understand the value
of not modifying stuff that doesn't badly need to be modified, and I see
certain advantages of maintaining the "target" part of "targetLang" in
connection with the one used for identifying the language that @target
points to (your own suggestion, Lou, BTW).

best,

  P.

On 25/04/12 16:33, Lou Burnard wrote:
> Sorry, I disagree.
> 
> We currently use @targetLang on <schemaSpec> with quite a plausible 
> meaning. If that meaning isn't appropriate for the new attribute, it's 
> the new guy who has to be renamed not the existing one.
> 
> 
> On 25/04/12 15:17, Piotr Bański wrote:
>> On 25/04/12 14:45, Martin Holmes wrote:
>>> I think the original @targetLang on<schemaSpec>  is doing a completely
>>> different job from the new one, isn't it? I think its purpose and
>>> semantics are clear from the description:
>>>
>>> <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-schemaSpec.html>
>>
>> Indeed, on the second reading I understand what these "objects" are
>> supposed to be. And you're right, namingLang would be a reasonable
>> choice, targetLang seems actually a bit unfortunate in this context.
>>
>>    P.
>>
>>> although I don't know if anyone has ever used it. Given that ODD is
>>> meant to be broader than TEI, someone may well use it at some point, if
>>> they're working with a specification that allows element or attribute
>>> names in different languages, so I'd recommend leaving it. I think it's
>>> OK to have two attributes with the same name doing different jobs in
>>> different contexts (although it's obviously not ideal). If we were to
>>> make a change, I'd recommend changing schemaSpec/@targetLang to
>>> @namingLang, or something like that.
>>>
>>> Cheers,
>>> Martin
>>>
>>> On 12-04-25 04:26 AM, Piotr Bański wrote:
>>>> Thanks to Stuart's wiki list, I noticed that targetLang is now defined
>>>> in two places: (a) att.pointing (new) and (b) schemaSpec (old).
>>>>
>>>> They don't differ in the datatype, but in the semantics ((a) identifies,
>>>> (b) apparently prescribes) and the context ((a) accompanies @target and
>>>> points at a remote resource, (b) acts locally; the Schematron rule for
>>>> (a) is not applicable to (b)).
>>>>
>>>> (b) is listed in 23.4.1 (description pulled from the spec, there is no
>>>> independent discussion of it), and actually, I don't fully understand
>>>> what it is meant to do: "specifies which language to use when creating
>>>> the objects in a schema if names for elements or attributes are
>>>> available in more than one language".
>>>>
>>>> What should I do?
>>>>
>>>> 1. leave them as they are, effectively (b) becoming now a local override
>>>> of (a), just like in the case of e.g. @type (but note that the situation
>>>> is not fully analogous!)
>>>>
>>>> 2. rename (a), but it makes so much sense to leave this name, cf. [1],
>>>> because it really nicely goes together with @target, and renaming it to
>>>> the originally suggested "refLang" would create the somewhat misleading
>>>> network of @target, @refLang (supposed to always accompany @target) and
>>>> @targetLang (supposed NOT to accompany @target).
>>>>
>>>> [1]:
>>>> https://sourceforge.net/tracker/index.php?func=detail&aid=3288293&group_id=106328&atid=644065
>>>>
>>>> 3. create a ticket for renaming (b) to e.g. objectLang (as its
>>>> description suggests)?
>>>>
>>>> Thanks,
>>>>
>>>>     P.
>>
>