Lists Home |
Date Index |
- From: Leigh Dodds <email@example.com>
- To: firstname.lastname@example.org
- Date: Tue, 16 Nov 1999 11:41:02 -0000
> >right to ignore external entities, not to barf, just to ignore them. If
> >the system is specified in this way, nobody will send external entities.
> >(Which lord knows they shouldn't be doing in ecommerce-land anyhow).
> Nope, sorry, not that easy, unless you specify the use of a specific
> processor or put big warning labels throughout indicating that external
> entities should not be used.
Aren't those "big warning labels" going to be the schema/DTD/messaging
format defined for your EDI/E-Commerce application. If you're
in violation of that format then you message/data/whatever deserves
to be junked.
If you use entities internally thats fine, so long as they get
replaced before the XML 'hits the wire'.
The problem applies equally to say, malformed element names - if
its outside the spec it invalid.
I can see why perhaps there would be a need to gracefully recover
from such cases, and attempt to get *something* out of the document,
but if we're talking EDI/E-Commerce then we're probably talking
atomic transactions as well, so getting *some* of the data
just isn't enough.
If you've defined a standard messaging format that stops a lot
of features being used, then I can also see some advantage in
not having a parser which supports those features, if theres
a significant performance/overhead difference, and I know
the format is never going to be revised to add in any
other those features.
So, conform to your spec and you'll be fine. It means that
you may have to do additional work to ensure that the
fragments/documents/messages don't use any illegal features, especially
if you're handling fragments from outside your own domain.
I think you've already correctly pointed out (in your Packaging/Profiling
posting) that this type of validation needs some attention.
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)