Re: MathML entities don't degrade gracefully

> This, on the other hand, would mean forking XML and creating something  
> that's almost XML but not quite-

No, as I said I think, given that the mechanism by which an XML parser
finds (or does not find) an external DTD is more or less unspecified,
this does not require forking XML, certainly any XML parser with catalog
support already could be made to accept those two examples.

> thereby making it incompatible withdeployed browsers 

Ye, as you showed at the start of the thread. If you pass an undefined
entity to (most) browsers in XML mode  you get a very agressive
rejection of the whole document. If you put keeping existing behaviour
as top priority then there is nothing you can do to change that, you are
saying you want to keep that error behaviour. If you do something
(anything) to make the entity have a default definition or in some other
way prevent the rejection of the entire document then it will be
incompatible with deployed browsers.

> and the existing XML toolchain.

I think this can work with existing XML toolchain. It stretches things a
bit and isn't without problems, but no solution here is without
problems, it's just a judgement call on which is the least horrible
solution.

> we should go all the way to "XML5" on the first try specifying
> non-Draconian streamable error handling, adding MathML entities as
> built-in, removing *all* restrictions on what characters can appear in
> a Name and removing DTDs all in the same go.

Yes the idea of building in all the entities has come up several times
in "XML 2" (aka XML 5) discussions on xml-dev and elsewhere.

David

Received on Friday, 25 April 2008 13:00:00 UTC