> -1- charclass Attribute > Yves, Isn't CSS2 a style sheet specification? Does it allow me > to restrict the translation to Katakana or 7-bit ASCII or Uppercase > without forcing me to give other details? If I remember correctly, > the reason we didn't use CSS2 here was we felt it was like using a > sledgehammer where a tack hammer was needed. However, if it gives > us what we want, i.e. restrict the translation to some character > class, without imposing a lot of syntax, it could be acceptable. > Does anyone know of something comparable but simpler? The problem is that we ended up using nothing at all: 1.0 has no specification for the value of charclass (in any way). Which is not too good for interoperability :) The CSS2 notation is made of Unicode character ranges, not keywords like 'katakana' etc. So it's somewhat more complicated, but also much more powerful since it's not limited by pre-defined keywords (which can be complicated: what range corresponds to the keywords: e.g. 'katakana' includes the phonetic extensions or not? We would have to define the ranges along with the keywords. Katakana only would be charclass="U+30a1-U+30fe" or charclass="U+30??" Katakana with Katakana phonetic extensions would be charclass="U+30a1-U+30fe,U+31f0-U+31ff" Maybe we can device something based on that notation but simpler (without the wildchars)? > -2- XLIFF Namespace > I didn't know if this was verified with Karl Best, Director of > Technical Operations at OASIS, or not. According the RFC > referenced, he maintains the namespace identifiers. So I contacted > him. Our thread is included below. In summary, the namespace Yves > proposes works. However, if this NSS is pointing at the spec, should > we put in the type "document"; e.g. "urn:oasis:names:tc:xliff:document:1.0"? > This is based on the the RFC3121, ftp://ftp.isi.edu/in-notes/rfc3121.txt . Looks good to me. cheers, -ys