Re: Comments on XML Part 1 from Japanese experts

>So I think the XML naming rules should remain pretty much as the are,
>and not restrict anything more.   

The point I was making is that application profiles/usage scenarios
will likely enforce the desried restrictions *without* any changes to
the XML spec. I think that's reasonable.

>We need an XML annex on localization. The rest of the world will not
>go away!! 

This is a good idea.

>It should start off by appropriating Gavin Nicol, et al's internet
>draft on Internationalisation.  Then, as additional sections, it
>should have particular locale-dependent sections. For example, for
>Japan it should mention that it strongly recommends that all 
>non-JIS 208 characters should be entered with numeric character
>references.  

Right. I have no problems with *profiles* like this being done. I do
not think they need to be part of the language specification.

>To follow ISO 10646/Unicode: lets allow hankaku katakana, but
>*strongly* deprecate them. It is not XML's job to tell users which
>characters they cannot use in their documents. A note should be added
>to the XML default SGML declaration. 

Like the above, I agree. Profiling should be outside the language.

>So I strongly recommend that ideographic spaces (indeed, all spaces)
>should be valid white-space. However, I certainly also agree 
>that a comment should be put in that they are *strongly* deprecated
>in markup, and that they can be replaced by a space (two??) at 
>any time by any XML process. A comment should be added to the XML
>default SGML declaration. 

I have no problems with deprecating them, but disallowing them will
make life harder for people *using* XML.

>I agree with the Japanese here. The appropriate way to handle extra
>characters is by entity references or by some special element
>invocing a networked retrieval, not by private use characters (or any 
>other mechanism that compromises Unicode's 1 character = 16 
>bits).  A note should be added to the XML default SGML declaration.

Count me as disagreeing. I think we should *allow*, but not
*recommend* private use characters and surrogates. Think of them as
being implicit SDATA entities...

>I see that the font companies are talking about some mechanism of
>delivering fonts over the net. Does anyone know if this is just a
>"Type-on-call"-on-the-web pay service?  

Most of the proposals I have seen are not really "font delivery",
though there is lot's of talk.

>As (Gavin &) I have said before, XML needs some mechanism for
>downloading extra glyphs.   

Yes. A standard mechanism for defining the semantics, properties, and
glyph/glyph image selection for characters needs to be built.

Received on Tuesday, 3 June 1997 11:30:59 UTC