on altIdent #2049
Comments
|
Instructions for Council subgroup (@sydb, @ebeshero, @npcole, and special guest @martindholmes): Fill in “1” (favorite), “2” (second favorite), “3” (third favorite) in your three favorite methods for encoding what we currently encode as Instructions for anyone else who would like to express an opinion: Edit the table adding a column for yourself, and let us know your preferred method(s) using the same numbering system.
|
|
Instructions for Council subgroup (@sydb, @ebeshero, @npcole, and special guests @jamescummings and @martindholmes): In the column under your initials fill in a checkmark (‘✓’, U+2713) for those elements for which you think Instructions for anyone else who would like to express an opinion: Edit the table adding a column for yourself, and let us know where you think Explanation of columns:
|
|
I'm sure this was covered in the Council discussion, but I wasn't there so I'm going to ask: Aren't we confusing a human-readable title with a Formal Public Identifier here? "Names and Dates" is a heading or a title; an FPI should presumably be some sort of unique identifier such as a URI, shouldn't it? We would expect "Names and Dates" to be translated into another language when the schema is not expressed in English, but would we want the FPI to change? |
|
No, I don’t think we are confusing the title (e.g. “The TEI Header”, which is found at HOWEVER, I believe I have just discovered that I have the “FPI” and “heading” columns reversed in the table in the Addendum of the initial post. I have a meeting in 1 min, but after that plan to check & fix if needed. |
|
Worth mentioning there is an FPI → URI methodology: |
|
Yeah, I had the columns in the Addendum above reversed. Fixed now. |
Plan,
|
| parent | has@ident? |
has child <altIdent>? |
SB | EBB | JC | MH | MS | HC | RV | HBS |
|---|---|---|---|---|---|---|---|---|---|---|
| application | direct | NO | ? | ✗ | ✗ | ? | ✗ | ✗ | ✗ | ✗ |
| category | NO | NO | ✗ | ✓ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ |
| language | direct | NO | ✗ | ✗ | ✗ | ✓ | ✗ | ✓ | ✓ | ✓ |
| paramSpec | att.identified | yes | ✗ | ✓ | ✗ | ✓ | ? | ✓ | ✗ | ? |
| schemaSpec | att.identified | yes | ✗ | ? | ? | ? | ✗ | ✗ | ✗ | ? |
| transcriptionDesc | direct | NO | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ |
| new | places | go | be- | low | here | (-: | :-) |
summary of step (2) results so faruncontroversialThat is, subgroup agreed in 1st round of voting. per step (1)
do not already have
|
|
So, there are 2 elements left to discuss for step (2), on
|
|
On
I presume that should be "allowed inside Other than that, I think I find your argument convincing. My reason for voting for here was that I'm constantly aware that languages (especially endangered or extinct languages) are frequently described, identified and referred to in many different ways by different communities, but of course this really has no bearing on |
|
Yes, @martindholmes, the MarkDown source of that snippet says so it seems very odd that you are not seeing the backticks. (Even your copied quote from my post has the tags in it without the backticks.) Anyway, |
|
@sydb I wasn't talking about the backticks; I was talking about the element name "altIdent", which I think is a typo for "language", You wanted to say (I think) that you can use idno inside language, so you don't need altIdent. Instead you implied that you can use idno inside altIdent, which isn't true. |
|
My motivation was identical to Martin's, as was my mistake in not realizing that As for |
|
Right! Thank you, @martindholmes. I have just fixed that, which means that future readers of this exchange will be quite confused. :-) |
|
OK, @hcayless, that makes it 6:2 against putting As for |
more on
|
|
re: @sydb / @hcayless : I think that your understanding of |
|
In general it seems perfectly plausible to have alternative forms of a parameter name. Look at the spec for any Unix command. |
|
Also @sydb you did say before "if no consensus can be reached I will (begrudgingly) leave |
|
Yes, @lb42, it is completely plausible. And yes, @martindholmes, I did say that. But (with the possible exception of you) we have just reached consensus in that all of Council (including HC and EB, and also JC) have agreed to dropping it. We (including MT) believe, BTW, that there is no software in the world that would have any idea what to do with The Unix-command switch duality that both @lb42 and I brought up is (in my mind) a reasonable but misleading analogy. After all (JC pointed out), the We could all think of use cases; none of us could come up with any compelling use cases. |
|
@martindholmes @sydb Here is what persuaded me toward consensus on removing |
|
Or just having a 2nd |
Where we are so far — Or, Plan ReduexHere are the steps from the original post on this ticket, annotated with what has been done so far.
So I think there is nothing else to do for this ticket now except to change the end-deprecation date to mid-October. Then, in mid-October we do steps 8, 9, 10, & 11. (Then, in 2023 we do step 14.) Notes[1] I set the valid-until date to 2022-07-14 back when I did this (2021-10-11), in order to have a date that was at least 6 months in the future and perhaps even 6 months after the next release. However, the PR was not merged until 2022-04-02, a mere ~3.2 months before the valid-until date. I think we should reset the valid-until date to 2022-10-21, and plan to just do so soon. |
Change model.glossLike into 2 new classes: model.identInfo [gloss euqiv] and modelidentInformation [altIdent and model.identInfo]. Change all references to model.glossLike (whether on <memberOf> or <classRef> or in prose) to one of the two new classes.
Oops. I forgot to actually add the new files to the repo. Note that previous commit was most of the work of step 8.
|
TTD? Revisiting this after months of inattention.
Checking now:
Therefore I think we should (right now):
|
(Note: This issue wraps in the problem initially posted in #1859, the problem later discovered in #1859, and one of the last comments of #1919, namely that “there are some TD elements that probably should not have
<altIdent>, either;<modelGrp>, e.g.”.)Problems
The problems with
<altIdent>are:<dataRef key="teidata.xmlName"/>.<moduleSpec>(with@typeof "FPI"). Which would be a good thing, as its use there is simply incorrect — it does not match the definition of<altIdent>at all. But we need to find another way to represent the FPI of each module (which is needed for DTD support). Towards the end of this comment please find a table of the identifier of each module along with the heading of its chapter and its FPI.Plan
So my suggested plan of action is, roughly, as follows.
<idno type="FPI">exactly where we currently use<altIdent type="FPI">.<altIdent>in their content model.<altIdent>in places identified in step 2 as no-nos.<altIdent>s are xsd:NCName (the equivalent of teidata.xmlName) EXCEPT those that are a child of<moduleSpec>and (or or?) have a@typeof "FPI".moduleSpec/altIdentto whatever we decided in step 1.<altIdent>is not allowed in the silly places identified in step 2.<altIdent>itself (to<dataRef key="teidata.xmlName" minOccurs="1" maxOccurs="1"/>)moduleSpec/altIdentto whatever we decided in step 1.<altIdent>method for indicating the FPI of a module.So, presuming Council agrees with this overall plan, the main issues that would need discussion and decision are discussed in the next 2 sections.
Where should
<altIdent>be allowed?The list of elements where it is currently allowed is:
<attDef>,<classSpec>,<constraintSpec>,<dataSpec>,<elementSpec>,<macroSpec>,<model>,<modelGrp>,<modelSequence>,<moduleSpec>,<paramSpec>,<schemaSpec>, and<valItem>.It is clear (to me, at least) that it is required for use in
<elementSpec>and<attDef>, and I believe that the Stylesheets will do the right thing in those cases (although I have not recently tested). I do not know what the Stylesheets do forvalItem/altIdent, but I can certainly imagine uses. At the moment (way past my bedtime), I am having trouble imagining what<altIdent>as a child of any of the others would mean.The basic idea, I think, is that use of
<altIdent>allows you to separate the name as used in the ODD (e.g., as the value of@key) and RELAX NG schema (as the pattern name) from the name of the construct in the schema and instances. Is that ever helpful for<dataSpec>or<paramSpec>?How should we encode the FPI of a module?
As mentioned above, my instinct is to use
<idno type="FPI">. Other possibilities include:<label>@n@fpi<head><ident><name><fpi><gloss><rs>Addendum
@identThe text was updated successfully, but these errors were encountered: