1--- 2title: Coverage Revision 3--- 4 5# Coverage Revision 6 71. Propose changing CoverageLevel to be data driven. Rough thoughts. 8 9Have a list of paths 10 11\- //ldml/identity/version => NONE 12 13\- ... 14 15\+ //ldml/localeDisplayNames/languages/language[@type="\*"] language:type=[en, und] => Minimal 16 17\+ ... 18 19\- ... 20 21Have special variables for 22 23- this language 24- this language's countries 25- this language's territories 26- ... 27 282. Current coverage: needs review 29 1. I put the tentative results in http://spreadsheets.google.com/pub?key=t5UzIpaSqcYBksSMtZp-f7Q&output=html 30 2. The more detailed files are in http://unicode.org/repos/cldr-tmp/trunk/dropbox/mark/coverage/. In particular: 31 1. http://unicode.org/repos/cldr-tmp/trunk/dropbox/mark/coverage/summary.txt 32 2. http://unicode.org/repos/cldr-tmp/trunk/dropbox/mark/coverage/samples.txt 33 3. http://unicode.org/repos/cldr-tmp/trunk/dropbox/mark/coverage/fullpaths.txt 34 35There is more to do, but I wanted to give a snapshot 36 37\- tune the weighting 38 39\- weight by draft level 40 41\- add collations, rbnf, plural rules, transforms (if non-Latin), etc. 42 43From John 44 45I've been doing some more thinking about how to deal with coverage in CLDR. It seems to me that we already have the notion that every XPath in CLDR should have some predefined number associated with it between 0 and 100 that denotes it's relative importance in terms ofcoverage, with 0 being absolutely critical, and 100 being not critical at all. See Appendix M of TR35 for a brief description of the levels. I think that if we could accurately quantify this using metadata, then it would be relatively easy for us to accomplish two things: 46 471). Filter out fields from the ST that we don't really need, since everything we do would be filtered based on a desired coverage level. 48 492). Allow individual users to set the filtering in the survey tool based on one of the predefinedcoverage levels as we already have in the spec, or actually any other numeric coverage level that they desire. 50 51So with this in mind, I would like to propose the following structure to be added to the supplemental metadata: 52 53\<coverageLevels> 54 55 \<coverageLevel value="nn" match="regular expression"/> 56 57 \<coverageLevel value="nn" match="another regular expression"/> 58 59.... 60 61\</coverageLevels> 62 63Finding the appropriate coverage level value would then be a matter of searching the coverageLevel entries in numeric order by value looking for a match of the path vs. "//ldml/" + "regular expression". In other words, we would not specifically include "//ldml" in the expressions, since they would all start with that. Once a given xpath's coverage level value was determined, it shouldn't be too hard for us to simply filter out fields whose coverage level was higher then the requested. I suppose that we will need some wildcards similar to what Mark has started working on in his path filtering proposal. 64 65