Re: Attribute values with unresolved entities
Michael Glavassevich <[email protected]> Sun, 25 Apr 2004 19:25:11 -0400
| Newsgroups | gmane.text.xml.sax.devel |
|---|---|
| Message-ID | <OF8798B188.9FA9878C-ON85256E81.007C855B-85256E81.0080A5DB@ca.ibm.com> |
This is a multipart message in MIME format. --=_alternative 0080A5D785256E81_= Content-Type: text/plain; charset="US-ASCII" [email protected] wrote on 04/25/2004 06:15:08 PM: > At 3:55 PM -0400 4/25/04, Michael Glavassevich wrote: > > The XML spec also says: "It is an *error* for a fragment identifier > (beginning with a # character) to be part of a system identifier." > What is an error? The spec defines it as: "a violation of the rules > of this specification; results are undefined. Unless otherwise > specified, failure to observe a prescription of this specification > indicated by one of the keywords MUST, REQUIRED, MUST NOT, SHALL and > SHALL NOT is an error. Conforming software MAY detect and report an > error and MAY recover from it." [1] The spec doesn't compel a parser > to detect errors (besides violations of validity constraints, > reported at user option), nor does it specify how a parser recovers > if it chooses to. > > > However, the SAX spec says that such errors correspond to calls to > the error() method in the registered ErrorHandler, if any. I think it > should be reported if the user has installed an error handler. > Silently throwing away data is a bad thing. The javadoc for error() refers to the definition of *error* in the XML spec, which doesn't require that they be reported, except at user option and only for validity constraints. The XML spec is clear that reporting this error is not mandatory. SAX doesn't say that parsers are required to report all errors defined in the XML spec to error() just by virtue of registering an ErrorHandler. I think it only imposes the more modest requirement that if an error is reported to an ErrorHandler which corresponds to the definition of 'error' in the XML spec, it must be reported to error(). Validity constraint violations are reported to the error() method when the validation feature is true. Unicode normalization errors will be reported to the error() method when the unicode-normalization-checking feature is true. Perhaps this should be under control of a feature for parsers which support reporting such errors. > -- > > Elliotte Rusty Harold > [email protected] > Effective XML (Addison-Wesley, 2003) > http://www.cafeconleche.org/books/effectivexml > http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulaitA > > > ------------------------------------------------------- > This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek > For a limited time only, get FREE Ground shipping on all orders of $35 > or more. Hurry up and shop folks, this offer expires April 30th! > http://www.thinkgeek.com/freeshipping/?cpg=12297 > _______________________________________________ > List: sax-devel, [email protected] > See: http://www.saxproject.org/ > https://lists.sourceforge.net/lists/listinfo/sax-devel Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: [email protected] E-mail: [email protected] --=_alternative 0080A5D785256E81_= Content-Type: text/html; charset="US-ASCII" <br><font size=2><tt>[email protected] wrote on 04/25/2004 06:15:08 PM:<br> <br> > At 3:55 PM -0400 4/25/04, Michael Glavassevich wrote:<br> > <br> > The XML spec also says: "It is an *error* for a fragment identifier <br> > (beginning with a # character) to be part of a system identifier." <br> > What is an error? The spec defines it as: "a violation of the rules <br> > of this specification; results are undefined. Unless otherwise <br> > specified, failure to observe a prescription of this specification <br> > indicated by one of the keywords MUST, REQUIRED, MUST NOT, SHALL and <br> > SHALL NOT is an error. Conforming software MAY detect and report an <br> > error and MAY recover from it." [1] The spec doesn't compel a parser <br> > to detect errors (besides violations of validity constraints, <br> > reported at user option), nor does it specify how a parser recovers <br> > if it chooses to.<br> > <br> > <br> > However, the SAX spec says that such errors correspond to calls to <br> > the error() method in the registered ErrorHandler, if any. I think it <br> > should be reported if the user has installed an error handler. <br> > Silently throwing away data is a bad thing.</tt></font> <br> <br><font size=2><tt>The javadoc for error() refers to the definition of *error* in the XML spec, which doesn't require that they be reported, except at user option and only for validity constraints. The XML spec is clear that reporting this error is not mandatory. SAX doesn't say that parsers are required to report all errors defined in the XML spec to error() just by virtue of registering an ErrorHandler. I think it only imposes the more modest requirement that if an error is reported to an ErrorHandler which corresponds to the definition of 'error' in the XML spec, it must be reported to error(). Validity constraint violations are reported to the error() method when the validation feature is true. Unicode normalization errors will be reported to the error() method when the unicode-normalization-checking feature is true. Perhaps this should be under control of a feature for parsers which support reporting such errors. </tt></font> <br><font size=2><tt><br> > -- <br> > <br> > Elliotte Rusty Harold<br> > [email protected]<br> > Effective XML (Addison-Wesley, 2003)<br> > http://www.cafeconleche.org/books/effectivexml <br> > http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulaitA<br> > <br> > <br> > -------------------------------------------------------<br> > This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek<br> > For a limited time only, get FREE Ground shipping on all orders of $35<br> > or more. Hurry up and shop folks, this offer expires April 30th!<br> > http://www.thinkgeek.com/freeshipping/?cpg=12297<br> > _______________________________________________<br> > List: sax-devel, [email protected]<br> > See: http://www.saxproject.org/<br> > https://lists.sourceforge.net/lists/listinfo/sax-devel</tt></font> <br> <br><font size=2><tt>Michael Glavassevich<br> XML Parser Development<br> IBM Toronto Lab<br> E-mail: [email protected]</tt></font> <br><font size=2><tt>E-mail: [email protected]<br> </tt></font> --=_alternative 0080A5D785256E81_=-- ------------------------------------------------------- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 _______________________________________________ List: sax-devel, [email protected] See: http://www.saxproject.org/ https://lists.sourceforge.net/lists/listinfo/sax-devel