Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Character Entities: An XML Core WG View
 I hope it will weed out the false claims like "HTML and MathML cannot use Schemas until they provide a way to define character entities" and we will instead hear ones like "we've tried using Schemas and DTDs together but find it unusable because ...". I think part of my disappointment with the document is that I think most of the comments I've seen re entities have been of the latter form, but the WG document just seems to have ignored them and just tried to argue against the claim that you "can not use a DTD", which is clearly a false claim anyway, so the end result is the document doesn't really address any real issues. The central thrust of the argument, that users can easily put the relevant declarations at the top of their document, relies on this statement being true: > However, different XML applications such as XHTML and MathML do not > need to declare differently named entities for the same > characters. If MathML and Docbook have different definitions it isn't at all clear what the user is supposed to do. Similarly MathML and XHTML. If you are given a combined XHTML +MathML DTD you have to look carefully at the order of combination to know what the end result is going to be. This causes no end of user confusion. It may be a defendable position that this confusion isn't within XML Core's remit to solve, but I don't think that the position taken by the document (that there isn't really any problem) is defendable at all. Personally I found that comment vaguely offensive (although I accept it wasn't intended that way) I've spent hundreds of hours pouring over the MathML entity set definitions, with an end result that the entities are not 100% compatible with HTML (or with docbook). The Core WG document seems to imply that we were incompetent since it just states so clearly that there is "no need" for any imcompatibility. Given that MathML was trying to be compatible with XHTML, with DocBook, and with other "traditional" mappings for the ISO entities, and that these sets were mutually incompatible it was clearly impossible for MathML to be compatible with all of them, and at the same time, the addition of several Unicode 3 characters means that the mappings of several ISO entity names should (or could) change to take advantage of the new characters. As I said in my initial response, it isn't clear to me that a solution can be devised that has acceptable costs in terms of changes to XML, but it is clear to me that there is a real problem in usability with the current procedures. The fact that an undefined entity is a well formed error (in the absence of a <!DOCTYPE) rather than a validity error means it's not really possible to experiment with alternative schemes in the context of XML 1.0. If 1.1 changed this so that undefined entities were always (only) a validation error you'd help a lot more people than you've helped by adding NEL to the line ending rules. It may be too late for 1.1 but keeping it on the agenda for any 2.0 is I think essential, but the purpose of the document appears to be to take entities of the Core agenda completely. David _____________________________________________________________________ This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus Scanning Service. For further information visit http://www.star.net.uk/stats.asp or alternatively call Star Internet for details on the Virus Scanning Service. 
|
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
|
|||||||||
