Fix inconsistency in datatypes of key= and ident=

[sydb]

att.identified: teidata.name
schemaRef: teidata.xmlName
specDesc: teidata.name
classRef: teidata.xmlName
elementRef: teidata.xmlName
macroRef: teidata.xmlName
moduleRef: teidata.xmlName
memberOf: teidata.name
dataRef: teidata.xmlName

[hcayless]

schemaRef/@key has no examples in the Guidelines, and I'm not sure what it would mean...All examples use @url

[ebeshero]

Council is puzzled by this ticket.
If it's identified, it needs to be a name. But what kind of name? Should they all be an xml name? Or perhaps some do need to be different kinds of name and these need to be treated individually?

@peterstadler argues (not unreasonably) that all should be teidata.name (i.e., colonized names allowed)
But @sydb notes that there may be cases in which having a colon is problematic or non-sensical.
So someone should probably examine the possibly problematic cases more closely.

[JanelleJenstad]

@sydb: Please explain this ticket a little better.

[ebeshero]

During Council VF2F subgroup @sydb notes that the string of text is the same but the datatype differs. That's the problem.

[JanelleJenstad]

Notes from Council for @sydb: The onus is on Syd to make the ticket clearer. Colons or no colons? Will they disturb the processing? Then we'll discuss again.

[sydb]

Just to be clear, it is not just the “colon or not” issue, although that is the biggest part. It is also that if we say “the @key of <A> should match the @ident of a <B>”, then (it seems to me) the datatypes of A/@key and B/@ident should be the same.

Not that it is likely that any of these change, but if one of them did, we could be wreaking havoc. And, for that matter, besides just the discordance the fact that they are not the same causes, it also makes it more likely that an ODD customizer falls afoul of changing one but not the other.

Also, it is not entirely clear to me that either a) we can fix this, or b) @peterstadler’s suggestion (“let them all have colons”) would not work. I hope to address each of these later. But for now, just to be precise about which attributes do not (and probably should) have matching datatypes:

attr	datatype	colons
att.identified/@ident [1]	teidata.name	allows namespace prefix
schemaRef/@key	teidata.xmlName	no colons
specDesc/@key	teidata.name	allows namespace prefix
classRef/@key	teidata.xmlName	no colons
elementRef/@key	teidata.xmlName	no colons
macroRef/@key	teidata.xmlName	no colons
moduleRef/@key	teidata.xmlName	no colons
memberOf/@key	teidata.name	allows namespace prefix
dataRef/@key	teidata.xmlName	no colons

[1] <attDef>, <classSpec>, <constraintSpec>, <dataSpec>,
<elementSpec>, <macroSpec>, <moduleSpec>, <paramSpec>, and
<schemaSpec>.

[lb42]

I suppose another wrinkle here is whether or not @key on these (formal specification) elements should have the same datatype as the generic @key provided by att.canonical : I'd say definitely not (it should remain teidata.text). But then maybe this @key should be renamed something else.

[sydb]

I agree that att.canonical/@key should remain teidata.text. (Although that said, any project using it should probably re-define it to be much more constrained, IMHO.) Renaming the @key used in formal specs is an idea that (I am embarrassed to admit) had not occurred to me. May be overkill (and should be on a different ticket if we really think it worth pursuing). But since they are not members of a class, but each individually defined, they could tightly reflect their semantics:
schemaRef/@key ⇒ schemaRef/@schema
specDesc/@key ⇒ specDesc/@spec ?
classRef/@key ⇒ classRef/@class
elementRef/@key ⇒ elementRef/@gi
macroRef/@key ⇒ macroRef/@macro
moduleRef/@key ⇒ moduleRef/@module
memberOf/@key ⇒ memberOf/@class
dataRef/@key ⇒ dataRef/@datatype
Or, since they are all pointing at @ident attributes, could all be @idref or @identRef.