[
Lists Home |
Date Index |
Thread Index
]
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.
|
