<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Ian Hickson wrote:
<blockquote
cite="mid:Pine.LNX.4.62.0906050737560.1648@hixie.dreamhostps.com"
type="cite">
<pre wrap="">On Mon, 18 May 2009, Brett Zamir wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.)?
</pre>
</blockquote>
<pre wrap=""><!---->
While there are arguments on both sides of whether this is a good idea or
not, I think the more important concern in this case is whether we can
extend XML in this way. I think in practice we should leave this up to the
XML specs and their successors. I don't think it would be appropriate for
us to profile the XML spec in this way.
</pre>
</blockquote>
<br>
While it is not my purpose to extend the debate on external DTD's, I
wanted to bring up the following points (brought to light after a
recent re-review of the spec) because it raises a few serious
issues which I believe current browsers are failing at, and if the
browsers do not address these issues, they would make claims for real
XHTML
5 support (as with XHTML 1.* and plain XML support) unworkable. While I
agree that any changes to XML itself should be up to the XML specs,
from what I can now tell, it looks like a closer adherence to the
existing spec would solve most
of the existing problems. I wanted to share the following points which
I think
could resolve most of the issues, if the browsers would make the
required changes.<br>
<br>
I was pleasantly surprised to find
that the spec seems to recommend solutions which I believe avoid the
more serious issue of single
point of failure problems.<br>
<br>
(The other complaints with DTD's, such as avoiding cross-domain DTDs
for the sake of
security or avoidance of DOS attacks might be an optional issue if that
may, in
combination with adhering to existing recommendations, satisfy
concerns, though I personally do not think such a risk is similar to
inclusion of cross-domain scripts.)<br>
<div class="moz-text-html" lang="x-unicode"><br>
So what follows is what I have gleaned from these various statements as
applied to current browsers. I can provide specific citations, but I
did not wish to expand this post unnecessarily (though I list
references at the end).<br>
<br>
The major issues which I think ought to be resolved by certain
browsers, as they do not seem to be in accord with the XML spec and as
a result, create interoperability problems:<br>
<br>
1) Firefox and Webkit, should not give a single point of failure for a
missing entity as they do now, (unless they switch to a validating
parser which finds no declaration in the external file and the user is
in validation mode), since such
failures in a
document with an external DTD are NOT well-formedness errors unless the
document deliberately declares standalone=yes.<br>
2) Explorer, which no longer seems to require in IE8 that the document
be
completely described by the DTD as I believe it had earlier (though it
will report errors if the
document violates rules which are specified), should, per the spec,
really only report
validation errors upon
user option (ideally, I would say, off by default, and activatable on a
case-by-case as well as preference-based basis). This will possibly
speed things up if the option could be disabled as well as let their
browser work with documents which violate
validation. But this issue is not as serious as #1, since #1 prevents
even valid documents from being interoperably viewed on the web.<br>
<br>
If these issues are addressed by those aiming for compliance, the only
disadvantages which will remain (and which are inherent in XML by
allowing the co-existence of
validating and non-validating parsers) are those issues described in
<a class="moz-txt-link-freetext"
href="http://www.w3.org/TR/REC-xml/#safe-behavior">http://www.w3.org/TR/REC-xml/#safe-behavior</a>
and
<a class="moz-txt-link-freetext"
href="http://www.w3.org/TR/REC-xml/#proc-types">http://www.w3.org/TR/REC-xml/#proc-types</a>
, namely that:<br>
<br>
1) some (entity-related) <i>well-formedness</i> errors (e.g., if an
entity is not defined but is used) will go hidden to a non-validating
parser as these will not need to load an entity replacement (which is
not a big problem, since a document author should
presumably have checked (with an application which does external entity
substitution) that their entities integrate properly with the text--it
is not as important, however, that they check for <i>validation</i>
errors, since as mentioned above, these need only be reported
optionally).<br>
2) The application may possibly not be notified by its processor of,
e.g., entity replacement values, if it is a non-validating processor
(though non-validating processors can also make such replacements). But
since these are, as mentioned above, not
to produce well-formedness errors, there is no single point of
failure here either (though there may be some missing content, but
indicated by an entity reference in the output display).<br>
3) A few validation issues, such as duplicate declarations (which might
include attribute defaults) can lead to undefined behavior (though
given that validation is only optional even for validating
applications, it seems all applications will have to deal with this).<br>
<br>
In other words, as the spec seems to indicate from my reading, users
going from one browser to the other will not face problems, unless:<br>
1) They
visit invalid documents and have the option to validate the document
turned on (it is only supposed to be an option) and expect other
browsers to report the same errors as well (not a big issue, since a
document which describes its validation constraints and then breaks
them is basically asking for trouble--and even here, the user is
supposed to have the option to view the document without validation).<br>
2) They expect to see the entity replacement text (and at least, this
is not a single point of failure, and in many cases, such as when
entities are merely used to represent symbols, the text can be fully
read without any disruption in the document flow). Of course, doing the
replacements
would be even better to avoid this problem, and the solution does not
require supporting validation.<br>
<br>
There are also the following optional issues which browsers might wish
to consider (though if these are not implemented, the above fixes alone
would address the most serious problems):<br>
<br>
1) Since even a non-validating processor is to inform the application
that it recognized but did not read an entity (if it does not replace
their references with content found in an external DTD), a browser like
Opera (the only one that I can tell does not report such issues, even
though it correctly does not lead to a single point of failure), might
(if not implementing #2 below) wish to
consider doing so, since a compliant processor at least is supposed to
report such issues to the application (to do with it as it sees fit).
But there is admittedly no obligation on the application to do
so, and in any case, such reporting is not to be a single point of
failure. But it still might be nice to distinguish the display of
entities which are not found from deliberately escaped entities (e.g.,
&myEnt; produced by a missing entity currently appears the same in
Opera (except in source view) as a deliberately escaped &myEnt;)<br>
2) Opera, Firefox, and Webkit (after the latter two fix the more
serious issue mentioned above) might also wish to consider expanding
their XML
support for their users to:<br>
a) Show a link to optionally expand each external parsed
entity references or other entities (if they don't do the following)<br>
b) Build on a non-validating parser to do automatic entity and
default
attribute value replacement, and attribute value normalization using an
external DTD (at least same domain ones). The XML spec only warns
against relying on this for the
sake of an application having the freedom to switch between
non-validating parsers which may or may not all take these
actions--this issue doesn't
impact interoperability for users (it only improves it), however, so
even if there is no desire to support validation, they can still offer
entity replacement, etc. to their users.<br>
c) Implement a validating parser which can do entity and default
attribute value replacement, and attribute value normalization from an
external DTD, as well as optionally validate the document at user
discretion. This should not slow things down for the user, since the
spec
itself indicates that reporting of validation errors is required "at
user option". This would give
the user the best of both worlds--the opportunity to fully read
XML/XHTML files online (and without any requirement to face a
validation performance cost), and if they are, for example, a document
author, they could choose to take a client-side performance hit to
optionally
check for validation. Of course, they'll need to load the external
files in either of these
cases to be able to do the replacements, but the document author will
NOT
need to provide full DTD validation in the external DTD, so users will
not be
forced to download DTDs reflecting the whole document structure, unless
the document author wishes to reference such files). Indeed, authors
might be
encouraged not to include such content in their DTDs (performing
validation offline) so that they and their users can reduce bandwidth,
unless their purpose is to transparently show the validation (though
DTD validation is of course not very strong).<br>
<br>
References:<br>
<a class="moz-txt-link-freetext"
href="http://www.w3.org/TR/REC-xml/#wf-entdeclared">http://www.w3.org/TR/REC-xml/#wf-entdeclared</a><br>
<a class="moz-txt-link-freetext"
href="http://www.w3.org/TR/REC-xml/#proc-types">http://www.w3.org/TR/REC-xml/#proc-types</a><br>
<a class="moz-txt-link-freetext"
href="http://www.w3.org/TR/REC-xml/#safe-behavior">http://www.w3.org/TR/REC-xml/#safe-behavior</a><br>
<a class="moz-txt-link-freetext"
href="http://www.w3.org/TR/REC-xml/#dt-vc">http://www.w3.org/TR/REC-xml/#dt-vc</a>
(validity constraint definition)<br>
<a class="moz-txt-link-freetext"
href="http://www.w3.org/TR/REC-xml/#include-if-valid">http://www.w3.org/TR/REC-xml/#include-if-valid</a><br>
<br>
regards,<br>
Brett<br>
</div>
<br>
</body>
</html>