> -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
