[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [xml-dev] Handling internal general entities with SAX
- From: David Brownell <firstname.lastname@example.org>
- To: "Devlin, Kurt" <Kurt.Devlin@westgroup.com>, email@example.com
- Date: Mon, 22 Oct 2001 12:05:12 -0700
> Yes, I realize that I want to "break" the XML rules, but I feel like my
> intentions are good.
I guess I'm of the camp that believes that kind of rule breaking
is not good, since it necessarily ties applications to particular,
and nonconformant, parser implementations. Neither of those
consequences seems to me like a good thing in the least.
> We definitely fall into the "no DTD" group for our data exchange. I had
> considered chaining an InputStream in before the Reader to "import" the
> entity declarations. This handles the case for all of the known entities,
> but not for unknown ones.
Sounds to me like you'd be better off using some magic syntax
that's not part of XML. You can't use XInclude for two reasons:
first, it doesn't work inside attributes; second, the latest drafts
still have that annoying XPointer support. And you can't use
XML entities, since you're saying that you can't constrain your
data language closely enough to preclude unknown entities.
You could cleanly layer a syntax like "$name;" on top of any
XML processor. In fact, it'd be simple enough to implement
some sort of SAX pipeline component that'd postprocess all
attribute values and character content to substitute "$name;"
values. The cost would be an extra scan over most characters
in the input data, but in terms of layering it's clean.