Warn if an attDef with a non-colonized @ident has a @ns attribute

[dmj]

As pointed out in [1] attributes with an unprefixed ("non-colonized") name are in the empty namespace as opposed to unprefixed element names that are in the default namespace. A @‍ns attribute on an attDef with a non-colonized @‍ident thus has no effect. It would bind the default namespace to the value in @‍ns but it would not put the attribute in this namespace.

[1] TEIC/Stylesheets#237 (comment)

[hcayless]

Summarizing the state of things: we want to do this in tandem with fixing the processing problem, so we're not acting on it immediately. The solution implicitly proposed here is that if a namespace is being set with @ns, then it should have a prefix set on the ident, and this prefix will be bound to the namespace. This isn't the only possible solution, but if we go with it, then we'll implement it in the Stylesheets and merge this PR.

[ebeshero]

Council SVF2F May 2021: We need to think about this. Questions and issues to follow up on:

• How should we define an attribute within a specified namespace? We should use the @ns attribute, but should @ident have a prefix, or should it be inherited from the root element of the ODD, or via the {Qname} notation?
• Is it really actually best to ensure we use a colon?
• We may need to define a new attribute for declaring the prefix. Or how do we declare the prefix so that we may refer to it, so that there's no name collision with a TEI attribute, for example?
• How is this related to Stylesheets ticket: ODD processing and custom attributes (of existing names) Stylesheets#237 ?

[sydb]

For SVF2F discussion of 2022-04-02: An ODD file to play with. It demonstrates (what we hope is) a solution to the problem w/o any changes to TEI or Stylesheets.

[raffazizzi]

Council decides to reject the PR because relying on namespace prefixes isn't a reliable solution. Prefixes are user defined and may be altered by XML processors at any time, while a prefix in @name wouldn't be altered and may break an ODD.

The solution linked by @sydb above, which relies on <altIdent> to allow @name to refer to the desired @indent, works for the time being to address the issue raised. Council will also open a new ticket to investigate a better solution that may, for example, introduce @ns to elements such as <attDef>.

[dmj]

Is there an issue that tracks the intended use of altIdent?

[ebeshero]

Hi @dmj : I think this is probably the ticket you are looking for: #2049

[sydb]

@dmj — No, I don’t think there is an issue that tracks the intended use of <altIdent>, just there is no issue to track the intended use of <gloss>. (The one @ebeshero links to is one about removing a particular use case for <altIdent>; it doesn’t really talk about how to use it.)
But it is an interesting question as to whether or not the Guidelines, or perhaps some user documentation about ODD, should discuss or demonstrate how to do this.