CLDR-15595 Reserve strings "undefined", "undefine", and "auto" in LDML

[sffc]

CLDR-15595

• [x] This PR completes the ticket.

This change describes all of LDML, so I wasn't sure exactly where to put it, so I made a spot for it in the top-level tr35.md.

[srl295]

Also There Oughtta Be A Test™, under TestDtdData (for the DTD) and perhaps something else to verify that it doesn't show up in actual data.

[srl295]

@sffc ping?

[sffc]

This seems like a tricky test to write. I need to figure out how to check the full set of identifiers.

[srl295]

This seems like a tricky test to write. I need to figure out how to check the full set of identifiers.

see the DtdData class

[macchiati]

That class can be used to iterate through all of the elements and all of their attributes, and check if any value, like " undefined" is valid.

On Fri, Oct 6, 2023, 17:24 Steven R. Loomis @.***> wrote:

This seems like a tricky test to write. I need to figure out how to check the full set of identifiers.

see the DtdData class

— Reply to this email directly, view it on GitHub https://github.com/unicode-org/cldr/pull/3278#issuecomment-1750894256, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACJLEMC4X7D5UCPK5WZVJLDX6APDZAVCNFSM6AAAAAA5AQLDQCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONJQHA4TIMRVGY . You are receiving this because your review was requested.Message ID: @.***>

[macchiati]

I made a quick program to do a test for that, but we would need to enhance the @MATCH values further before it could be a useful test. (https://github.com/unicode-org/cldr/pull/3328)

So that should not stand in the way of this PR.

[srl295]

I made a quick program to do a test for that, but we would need to enhance the @match values further before it could be a useful test. (#3328)

So that should not stand in the way of this PR.

So you have confirmed that the DTD doesn't currently use these terms?

Do we need to also check the data that there’s not some data element, such as a calendar or unit with <type name="undefine" … ?

I agree that if we're confident we're not already in violation of the requirement, this could proceed into the spec.

( i still think it should be located under #Valid_Attribute_Values though )

[macchiati]

So you have confirmed that the DTD doesn't currently use these terms?

No, I've confirmed something quite different: that we have no guarantees in the DTD that those terms cannot be used. (That is, there are @MATCH values that permit them.)

It would be possible to make a test that no current (and past?) CLDR data had values in {define, defined, auto}. One slight complication would be that the multivalue attributes would need to split the values to check.

On Mon, Oct 9, 2023 at 4:17 PM Steven R. Loomis @.***> wrote:

I made a quick program to do a test for that, but we would need to enhance the @match https://github.com/match values further before it could be a useful test. (#3328 https://github.com/unicode-org/cldr/pull/3328)

So that should not stand in the way of this PR.

So you have confirmed that the DTD doesn't currently use these terms?

Do we need to also check the data that there’s not some data element, such as a calendar or unit with <type name="undefine" … ?

I agree that if we're confident we're not already in violation of the requirement, this could proceed into the spec.

( i still think it should be located under #Valid_Attribute_Values though )

— Reply to this email directly, view it on GitHub https://github.com/unicode-org/cldr/pull/3278#issuecomment-1753102065, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACJLEMHLDZ2HLQNVGOYCCLTX6QBQZAVCNFSM6AAAAAA5AQLDQCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONJTGEYDEMBWGU . You are receiving this because your review was requested.Message ID: @.***>