[
Lists Home |
Date Index |
Thread Index
]
5/17/2002 9:00:30 AM, Elliotte Rusty Harold <elharo@metalab.unc.edu> wrote:
> It is impossible to use a
>non-validating parser with XSLT, or, more precisely, it is impossible
>to use a parser which does not read the DTD and resolve external
>entity references. Section 5.2 of the XPath spec clearly states:
>
>Entity references to both internal and external entities are
>expanded. Character references are resolved.
>
>There just isn't an option for leaving them out as you seem to want to do.
We keep circling back to the same issue: XSLT relies on a parser to
turn syntax into a data model that it recognizes. It says nothing
about what the parser should do with external entities, or Xincludes,
or anything else that had not been invented when the XSLT spec
was written <grin>, just that the parser had better not put them
in the data model if it expects XSLT to do anything sensible.
It is the woefully non-existent XML processing model that must
specify (or give the user the option to specify, or whatever) what
happens in these scenarios -- should a non-DTD aware parser simply
die when sees an entity reference? Should it quietly throw it away?
Should Xincludes get passed thru as InfoSet items or expanded?
In the meantime, all implementers can do is provide extensions to
let the user choose what to do.
I don't think that the scenario in which all parsers anyone will
encounter support DTDs is something we can simply assume. SOAP, and
possibly XML 2.0 "core" don't/won't support anything specified in
a DTD, so parsers optimized for a DTD-less profile will probably
become more prevalent in the future. Thus it's not at all clear what
the "right thing" is, and providing the option of simply throwing
away unexpandable entity references will be even more necessary.
|
