[
Lists Home |
Date Index |
Thread Index
]
Elliotte Rusty Harold wrote:
> All three
> cases (and probably others) will be passed to the XSLT processor
> which then is faced with an entity reference, and as the data model
> requires they must resolve that entity reference.
No. The point of saying that entity references are expanded is to say that
entities are *not a part of the data model* and therefore not visible to
the XSLT processor. The XSLT processor cannot throw an error when it sees
an entity reference, because it never sees an entity reference (and does
not know what one is).
The mapping in the XPath spec between the data model and XML syntax is
obvious and informal but technically not required since parsing and tree-
building is outside the scope of XSLT conformance.
As I've said elsewhere, this seeming recipe for non-interoperability (by
abstracting away from the syntax and instead restricting conformance to the
data model) is OK, because the XSLT 1.0 data model has always had an
obvious and unambiguous serialization through which any information in the
data model can survive upon re-parsing. (The direct address of
serialization issues in the specification of xsl:output, though not
required, also helped.)
There is a general assumption that XSLT can be applied to any well-formed
XML document using any conformant XML processor. I think this is a good
assumption. Also, I don't think there's any controversy or ambiguity about
what a root node would look like that is built as the result of taking an
XML document that contains external entity references and parsing it with a
minimally conformant XML processor (i.e. one that doesn't do any external
entity retrieval). Skipped entities are skipped.
Evan
|
