Move <fields> to top level of <dates> element

Description

Deleted Component: xxx-dtd

Per TC discussion 2012-Dec-12: Move the <fields> element from its current location -

under <dates><calendars><calendar type="xxxx"> (with data only for "gregorian") -

to being directly under <dates>, and applicable to all calendars.

Involves change to DTD, data, LDMLConverter, and coordination with JDK.

xpath

None

locale

None

Activity

Show:
TracBot
May 10, 2019, 3:48 AM
Trac Comment 2 by —2013-01-16T19:21:02.468Z

ICU needs to adjust for this, see http://bugs.icu-project.org/trac/ticket/9857

TracBot
May 10, 2019, 3:48 AM
Trac Comment 3 by —2013-01-24T23:37:02.980Z

This is being done in two phases in order to not affect the current Survey Tool vetting for cy, hy, ka, mn.

Phase 1 (changeset 8073) does the following:

  • Update the DTD to add <fields> at the new location (it remains at the old location for backward compatibility anyway)

  • Update elementOrder in CLDRFile, supplementalMetadata to match

  • Update prettyPath and CheckConsistentCasing for the new location (leaving support for the old location too, for now)

  • Update ldml2icu_locale.txt so NewLDML2ICUConverter uses the new location

  • For most locales, just move the <fields> data to the new location. Special handling for the following: (a) root , en - copy <fields> to the new location, leaving it also in the old location for now; (2) cy, ka, hy, mn - add a version of <fields> in the new location using what is currently winning in the ST; leave alone whatever exists for <fields> at the old location (hy and mn did not have anything there)

  • Don't change the info that ST uses to find data, e.g. PathDescriptions.txt and PathHeader.txt; don't update coverage data for new paths.

This way ST will continue working with the existing data at its current location for the locales being modified, but I can also pre-integrate CLDR data into ICU with the new location, and update ICU code accordingly. Once the ST data is rolled into XML then I can do phase 2:

  • Update the <fields> data in the new location for cy, ka, hy, mn with the final winning values

  • Delete the <fields> data at the old location for root, en, cy, ka

  • Delete the support for the old <fields> location in prettyPath and CheckConsistentCasing

  • Update the ST info to use the new <fields> location

  • Update the deprecated info in supplementalMetadata

  • Update coverage data to use new paths

TracBot
May 10, 2019, 3:48 AM
Trac Comment 4 by —2013-02-01T07:14:32.033Z

OK, made the final changes. John had already made some:

  • Under : update <fields> data in the new location for cy, ka, hy, mn with the final winning values and removed the data in the old location

  • Under this ticket: Update ST info in PathDescriptions.txt and PathHeader.txt

I just did this:

  • Remove <fields> data at the old location for root, en

  • Remove the support for testing the old location in CheckConsistentCasing (but leave the old paths in prettyPaths.txt, since it supports old paths too; it already had the new paths)

  • Update the coverage data to use the new <fields> location

  • Update the docs (and fix old validation errs as usual)

There does not seem to be a way in supplementalMetadata to deprecate an element only in one particular path and not another path, so I did not update the <deprecated> element.

TracBot
May 10, 2019, 3:48 AM
Trac Comment 6 by —2013-04-24T17:27:53.609Z

note these were missed by coverage -

Downstream, DojoBug:17071

TracBot
May 10, 2019, 3:48 AM
Trac Comment 7 by —2014-04-22T20:37:44.756Z

Milestone 23dres deleted

Priority

major

Assignee

Peter Edberg

Reporter

Peter Edberg

Reviewer

John Emmons

Labels

None

Components

None

Fix versions

None

Phase

None