On May 18, 2009, at 11:50, Brett Zamir wrote:
Henri Sivonen wrote:
On May 18, 2009, at 09:36, Brett Zamir wrote:
Section 10.1, "Writing XHTML documents" observes: "According to
the XML specification, XML processors are not guaranteed to
process the external DTD subset referenced in the DOCTYPE."
While this is true, since no doubt the majority of web browsers
are already able to process external stylesheets or scripts, might
the very useful feature of external entity files, be employed by
XHTML 5 as a stricter subset of XML (similar to how XML Namespaces
re-annexed the colon character) in order to allow this useful
feature to work for XHTML (to have access to HTML entities or
other useful entities for one, as well as enable a poor man's
localization, etc.)?
See http://hsivonen.iki.fi/no-dtd/ explains why DTDs don't work for
the Web in the general case.
While that is a thoughtful and helpful article, your arguments there
mostly relate to validation from a central spec.
No, my arguments don't relate to validation but to having to
dereference a URI that isn't under the author's control and that gets
copied around as boilerplate.
Also, as far as heavy server loads for frequent DTDs, entities could
be deliberately not defined at a resolvable URL.
There are existing XML doctypes out there with resolvable URIs, so
you'd need a blacklist to bootstrap such a solution.
The same problems of denial-of-service could exist with stylesheet
requests, script requests, etc.
No, styles and scripts are commonly site-specific, so there isn't a
Web-wide single point of failure whose URI gets copied around as
boilerplate.
Even some sites, like Yahoo, have encouraged referring to their
frequently accessed external files to take advantage of caching.
At least the serving infrastructure for those URIs has been designed
for high load unlike the server for many existing DTD URIs out there.
Furthermore, JS libraries have obvious functionality in existing
browsers, so it's unlikely that authors would reference JS libraries
as part of boilerplate without actually intending to take the perf hit
of loading the library.
The spec could even insist on same-domain, though I don't see any
need for that.
Without same-origin (as in not even performing a CORS GET), you'd need
to blacklist at least w3.org due to existing references out there.
(Note that for security, same-origin/CORS is must-have anyway.)
I also disagree with throwing our hands up in the air about
character entities (or thinking that the (English-based) HTML ones
are sufficient).
That's a text input method issue that needs to be solved on the
authoring side for text input of all kind--not just text input for
writing XML in a text editor.
Moreover, the browser with the largest market share offers such
support already, and those who depend on it may already view other
browsers not supporting the standard as "broken".
IE doesn't support XHTML or SVG which are the popular XML formats one
might want to load into a browsing context.
Loading same-origin DTDs for the purpose of localization is a semi-
defensible case, but it's a lot of complexity for a use case that
is way on the wrong side of 80/20 on the Web scale.
How so?
Localized sites are a minority on the Web, and chances that localized
Web apps would switch to a client-side localization method that relies
on server-side negotiation of the localization and requires XML to
work seem dim.
Even if it is a niche group which uses TEI, Docbook, etc. or who
wants to be able to build say a browser extension which can take
advantage of their rich semantics, this is still a use for citizens
of the web.
If you need a browser extension for content, you shut out users of
browsers that don't have the particular extension available. It's like
using Flash.
If people can push forward with backwards-incompatible technologies
like the video element, 3d-animation, or whatever, it seems not much
to ask to support the humble external entity file... :)
The upside of video and 3D is much more significant than the upside of
supporting external DTDs.
Besides, if the use case for DTDs is localization within an origin,
the server can perform the XML parse and reserialize into DTDless
XML. (That's how I've implemented this pattern in the past without
client-side support.)
That is assuming people are aware of scripting and have access to
such resources.
Localization with DTDs but without scripting is already tricky, since
one would need to tweak conneg. Furthermore, localization with DTDs
makes more sense for Web app UIs than static content, and Web apps
typically have server-side program code anyway.
Wasn't it one of the aims of the likes of XSL, XQuery, and XForms to
use a syntax which doesn't require knowledge of an unrelated
scripting language (and those are pretty complex examples unlike
entities)?
Web browsers don't support XSL-FO, XQuery or XForms. (XSLT support
isn't something that can be generalized to feature triage policy
applicable to new features today.)
(Btw, you and I discussed this before, though I didn't get a
response from you to my last post: https://bugzilla.mozilla.org/show_bug.cgi?id=22942
#c109 ; I don't mean to go off-topic but you might wish to consider
or respond to some of its points as well...)
Oh. I didn't make the connection. I didn't reply there, because using
Bugzilla as a discussion forum--particularly when the discussion turns
to advocacy--is frowned upon. Are there some particular points that I
haven't addressed here that you'd like to re-raise?
--
Henri Sivonen
[email protected]
http://hsivonen.iki.fi/
