Names of ‘tags’ and ‘types’

[michmech]

(Submitted by Jonatan Steller, talking about his DMLex implementation in TYPO3)

A more severe hurdle I encountered in the implementation were the names of several properties clashing with each other due to the fact that I implemented all tags as well as "RelationType" and "MemberType" in a single "Tag" table of TYPO3's database with multiple "type"s designating which type of tag was being provided. Crawling the spec repo and the mailing list I realise that an early draft of the spec contained and abandoned this logic before I first encountered it, but I would assume that other implementers may take a similar shortcut because it significantly reduces the number of database tables required to run DMLex. I provide a list of classes and properties that I needed to rename below - not to convince the LEXIDMA group to follow suit, but to document potential hassle around a spec feature where I found the names of classes and properties to be more confusing than elsewhere and possibly clashing in lazy implementations like mine:

• InflectedFormTag: renamed to "InflectionTypeTag" to align it with "DefinitionTypeTag"
• RelationType and MemberType: renamed to "RelationTypeTag" and "MemberRoleTag", respectively
• LabelTag, LabelTypeTag, PartOfSpeechTag, InflectionTypeTag, DefinitionTypeTag, TranscriptionSchemeTag: property "tag" renamed to "code" to avoid confusing the "tag" property with the "Tag" classes containing them
• LabelTag: property "typeTag" renamed to "labelType" to align it with other type indicators
• MemberRoleTag: property "role" renamed to "text" in alignment with other tags
• MemberRoleTag: property "type" renamed to "memberType" because it clashed with the type indicator needed for the unified table of all tags
• RelationTypeTag: "type" renamed to "text" because it clashed with the type indicator needed for the unified table of all tags
• RelationTypeTag: "memberType" renamed to "memberRole" to avoid conflict with the new "memberType" property now used for the MemberRoleTag class

I hope this makes some sense. I similarly aligned another property in the class "InflectedForm" where I renamed "tag" to "labelType" similar to how "Definition" has a "definitionType". The two illustrations I attached depict all classes and properties I needed to rename in a fuchsia colour. They were all necessitated either by changing from bottom-up to top-down relations or by simplifying all tags and tag-like classes into a single database table.

[michmech]

I think that the names of the various "tags" and "types" in DMLex make sense and are the naming pattern is consistent.

Implementors are free to implement them using different names if they prefer and still be DMLex-compliant (provided we don't have a normative serialization for that environment, which for TYPO3 we don't).

No further action is required, in my opinion. I suggest to close this issue.