On Fri, 19 Jun 2009, Brett Zamir wrote:
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
You can easily include a cross-domain script using a cross-domain DTD; just
attach the malware as
!ATTLIST body onload CDATA { sniper.shoot(); }
and hope for the worst.
Chris
2009/6/19 Kristof Zelechovski giecr...@stegny.2a.pl:
You can easily include a cross-domain script using a cross-domain DTD; just
attach the malware as
!ATTLIST body onload CDATA “{ sniper.shoot(); }”
and hope for the worst.
Chris
You need to own the external subset, though, in order to
Ian Hickson wrote:
On Mon, 18 May 2009, 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
On Mon, 18 May 2009, 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
The localization of your site starts with connection negotiation where the
representation of resources served depends on the browser's language of
choice. Configuring the server to support this needs some technical
expertise, and so does using a server-side scripting language.
External DTD
Henri Sivonen wrote:
On May 18, 2009, at 11:50, Brett Zamir wrote:
Henri Sivonen wrote:
On May 18, 2009, at 09:36, Brett Zamir wrote:
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
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
AFAIK, WebKit is not going to validate XML, they say it makes page load too
slow. 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
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.
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
Using entities in XSL to share code was my mistake once too; it is similar
to using data members not wrapped in properties in data types. XSL itself
provides a better structured approach for code reuse.
Being able to use localized programming language constructs is at the same
time trivial
Hello,
I don't want to go too far off topic here, but I'll respond to the
points as I do think it illustrates one of the uses of entities
(localization)--which would apply to some degree in XHTML (at least for
entities) as well as in XML.
Kristof Zelechovski wrote:
Using entities in XSL
13 matches
Mail list logo
