Rick
Thanks for your comments. Do you think that these proposed changes have
to be incorporated before we can start the second CD ballot?
> I would like to see an option first element
> <title>
> and preferably
> <p>
> <emph>
> <span>
> as in Schematron, to allow documentation. Consequently, we need a top
> level element, such as <schema>.
I would like to follow what RELAX NG does. So we have to discuss.
I can raise this issue as part of the Japanese member body comments
on the second CD.
>
> I would like to see the ability to declare a unicode normalization type.
> Internationalisation libraries offer these, so it should not increase the
> difficulty of implementation. The normalization is done by notionally
> transcoding the input document to Unicode using a particular normalization
> form. If no normalization is specified, then the implementation should use
> no normalixation (if the platform provides it) or the default
> normalization otherwise.
Again, we have to discuss.
I quickly read "Character Model for the World Wide Web 1.0: Normalization",
which is a still working draft.
It says:
When recipients cannot count on early normalization, then some
form of late normalization is the only way to ensure proper
results of string comparison and other normalization-sensitive
operations.
So, I can argue that the addition of normalization modes makes sense.
But I can also argue that normalization modes should not be added, since
XML 1.0 already assumes early normalization.
I would like to discuss as part of the comment disposition on the second
CD. Again, I will raise this issue.
> In section 10, Conformance, the last paragraph is not appropriate, I think.
>
> The last sentence amused me a little: imagine using MUST and MAY for this:
> "Users MAY argue that CDRL makes implementions unnecessarily difficult".
My apologies for the confusion. The last two paragraphs are editiorial
notes. I am going to fix this before the second CD ballot.
> For the example A3 & A4, Japanese Kanji, I think
>
> 1) there should be a more exact romaji (and why not Japanese?) reference
> preferably with year
http://en.wikipedia.org/wiki/Ky%C5%8Diku_kanji
This is a web page. I will add this as part of the bibliography.
> 2) why not put in the complete lists? Two items per line to save paper.
> The reason to do it is just for completeness and to add value to the
> Japanese translation. I think this should entirely be a decision for the
> Japanese delegates based on their convenience.
I would like to add some lists only because they clearly demonstrate
that ranges are useless.
The complete lists for Japanese education kanji require 766 more
characters. And Japanese users would probably request other lists:
toyo kanji, joyo kanji, and jinmeiyo kanji. The Japanese committee
might want to introduce such lists (using kanji characters rather than
character references) when it creates a JIS from this work. But we
would like to keep this standard short.
http://en.wikipedia.org/wiki/J%C5%8Dy%C5%8D_kanji
http://en.wikipedia.org/wiki/Toyo_kanji
http://en.wikipedia.org/wiki/Jinmeiyo_kanji
> 3) of course, if Korea has similar lists, that too could be added
Korea probably does not need such lists, since they do not usually use
kanjis any more. But I find some lists from Singapore.
Probably, Chinese and Taiwanese also have similar lists.
Each list takes a few pages. I would like to wait for member body
comments from Korea and China.
Cheers,
-- MURATA Makoto <murata@hokkaido.email.ne.jp> -- DSDL members discussion list To unsubscribe, please send a message with the command "unsubscribe" to dsdl-discuss-request@dsdl.org (mailto:dsdl-discuss-request@dsdl.org?Subject=unsubscribe)Received on Sat Nov 4 13:30:02 2006
This archive was generated by hypermail 2.1.8 : Mon Nov 06 2006 - 14:43:02 UTC