[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: UTF-8+names
David Carlisle wrote: > > > > If so, isn't this entirely a software issue? Can't existing XML > > browsers and editors just be extended so as to support *names* for > > characters, and we leave the encodings alone? > > they could, but requiring tools to enter data appears to be > completely contrary to the spirit of XML. I didn't say requiring. There is absolutely nothing that I implied as being required. I said that the original user need seems to be satisfiable by enhancing the current tools. If user A has that need, she can choose any tool that addresses her need. If user B doesn't have that need, she is still able to share documents with user A by using the tools she has always used. Both will be using UTF-8 or UTF-16 or ISO-xxxx and be happy. There will be no need to convert millions of existing XML documents to UTF-8+names just to make them more readable, because the software can handle this. The impact on existing software will be zero, apart from those tools that will voluntarily be enhanced. What I am saying, again, is: There is obviously a user need. This user need seems to be a need for better software, not a need for a new standard, even in the form of a new encoding of Unicode, which is so invasive. > If you're going to > always hide data entry behind some interface what's the point > of a textual format? The data is Unicode. It is Unicode today, it is Unicode in Tim's and John's proposal, and it is Unicode in the suggestion I am now making. My point is that, if input/display of certain Unicode characters is difficult with today's software, a good answer is probably to enhance the software to facilitate input and display of "difficult" characters. Again, it is NOT all of the software that needs to be enhanced. Nor does all of the enhanced software need to be enhanced in the same way and at the same time. Interoperability is guaranteed by the current XML and Unicode standards, since the encoding itself won't change. > > If I tell people that to get a right arrow in MathML they need to go > > <mo>&rightarow;</mo> > > Then they know how to enter that (whatever system they are > using). If on the other hand I had typed the above using a > fancy API that entered teh character directly into this email > (rather than emacs over a vt100 terminal emulator dialup > line:-) Here you seem to be saying that a software-specific solution won't address 100% of the use cases, because there is a fraction of users that have no option but to use an old editor, but still need the ability to enter characters by name. How many are they? Does their number justify the introduction of a new kind of complexity that will affect the whole spectrum of XML tools? Alessandro > then what you would be seeing would be > > <mo>-missing-glyph-marker-</mo> > or > <mo>-a-right-arrow-</mo> > or > <mo>-random-latin-1-characters-corresponding-to-utf8-code-for- > 8859-</mo> > > depending on how your system is set up, and either way this > gives essentially no information about how you are supposed > to enter that character on your system (short of cutting and > pasting it from my message). > > You don't need the entity names of course: & # 8 5 9 4 ; > would do as well, but people find it easier to remember names > than numbers. > > The problem is of course that fragments such as the above are > not well formed, since they reference an undefined entity, If > you add a DOCTYPE it becomes well formed but no longer a > fragment that can be pasted into a document. This proposal > doesn't really address that issue either, as you still need a > declaration at the top of the file. A preferred solution for > MathML at least would have been for XML 1.1 to say that an > undefined entity was a validity (not WF) error (this is > already the case if the DOCTYPE has an external component > that has not been read) > > If this were the case one could layer alternative entity > definition mechanisms over XML parsing. > > Strangely XML core WG declared there wasn't really any > problem with existing uses of entity references. > http://www.w3.org/XML/Core/2002/10/charents-20021023 > > So according to that view, the current proposal appears to be > addressing a non-problem. (Strange as there appers to be an > overlap in authorship.) > > David >
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|