W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2009

[whatwg] External document subset support

From: Brett Zamir <brettz9@yahoo.com>
Date: Mon, 18 May 2009 18:21:05 +0800
Message-ID: <4A113691.8050906@yahoo.com>
Kristof Zelechovski wrote:
> AFAIK, WebKit is not going to validate XML, they say it makes page load too
> slow.
Yes, I can see validation would be a problem, and see little use for 
that except local file testing. But I'm just talking about using the DTD 
to access entities, not to do validation. While this does involve 
another HTTP request (as do external stylesheeets, scripts, etc.), 
browsers could, as they do with such files, cache the files.
> Besides, entities introduce a security risk because it can contain
> incomplete syntax fragments and they can open a path to XML injection into,
> say,<![DANGER[<span title="&malicious-entity;">sweet kittens</span>]]>.
> So XML processors often refuse to load cross-domain DTD or ENTITIES.
>
>    
Then, cross-domain entities could be restricted... I'm just thinking one 
should be able to at least have /some/ way to use them, even if you have 
to save the file in the same domain.
> There are several XHTML entities that are indispensable for authors, namely
> those that disambiguate characters are invisible or are indistinguishable
> from others in a monospaced typeface.  These include spacing, dashes, quotes
> and maybe text direction (deprecated).  Converting them to their
> corresponding characters deteriorates the editing experience in an ordinary
> text editor.  As far as codes for letters are concerned, text in a non-Latin
> script would consist mainly of entities, which would make it extremely hard
> to read, so this approach is not practical.  An editor limited to the ASCII
> character set would be better off using a transliteration scheme and a
> converter.
>    
Yes, if the whole document were written in that fashion, and it was not 
a localization. But for those who are already using programs which 
support non-Latin scripts, such documents may still take advantage of 
entities (or even have the entities themselves be in a non-Latin 
script). For example, my "Chinese XHTML" ( 
http://bahai-library.com/zamir/chineseXHTML.xml and 
http://bahai-library.com/zamir/chineseXHTML.xsl ) (can view in Safari, 
Firefox, or Opera), which allows tags, attributes, and CSS in Chinese 
characters roughly equivalent to the XHTML tag names, as long as the 
stylesheet is attached, could also use Chinese entities in the XML 
document if such external doctypes were supported (the example uses one 
in the internal subset). This raises another use for entities--a simple 
introduction to preparing XHTML documents in all regards, regardless of 
one's native language. (And I used entities in the XSL file too, thereby 
highlighting another example of entities--the ability to automatically 
and transparently share /all/ of my code, including localization code 
for anyone who wished to make their own localization or borrow mine for 
other uses.)
> However, as some of the entities are indispensable, a DOCTYPE is required.
> The browsers may support built-in entities but XML processors used to
> process XHTML documents need not.  Providing a set of the entities needed
> in-line is easy;
If you mean providing them in each document, then that, while easy, is 
already supported, but is a large use of bandwidth, and not to mention 
quite a pain to have to copy into each document and maintain...
> however, the problem is that some validating processors
> like MSXML require that the DTD, if provided, should fully describe the
> document; providing entities only is not supported by default and the
> processor refuses to load the document.  That means a DOCTYPE for XHTML is
> necessary and should be provided by WHATWG (or by an independent party).
> This DTD should be external in order to use parameter entities and, of
> course, to make the document smaller.  It cannot, of course, define all
> nuances of XHTML, but an upper approximation would be sufficient.
>
> The problem, of course, is maintenance, since XHTML is in flux.  XHTML is
> currently described formally by a RELAX NG grammar and maintaining a
> separate DTD would double the work to do so it would be best to be able to
> generate the DTD automatically.  However, the converter I was advised to use
> was unable to produce a DTD from the grammar because it is too complex for
> the DTD formalism (of course).
>    
Hmm... Good point. Still, it is surmountable...

> Best regards,
> Chris
>
> Aside: Note that you cannot use DocBook with MSIE directly; a bug in the
> default XSLT processor causes an error in initialization code.  This kills
> all transformations, whatever your document is.  (I do not know about TEI.)
>    
I've used XSL successfully before in IE, but haven't used it for some 
time... Right now my "Chinese XHTML" which really did work for me in 
Explorer before when I outputted in GB2312 is not working now, though 
that may be due to the fonts on my system now.

Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090518/0671dbb8/attachment.htm>
Received on Monday, 18 May 2009 03:21:05 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:12 UTC