Move <fields> to top level of <dates> element
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.
Trac Comment 7 by —2014-04-22T20:37:44.756Z
Milestone 23dres deleted
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.
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