Re: Inconsistent SAX parser behaviour: UNICODE CHARACTER REFERENCES & ENTITIES ?

> Hi,
> 
> I have been experimenting with entities and character references and 
> have now reached a state of total confusion. 
> 
> According to my knowledge about ENTITIES and character references the 
> subtle but important difference between the two is that the parser (is 
> supposed to) expand character references immediately. 
> 
> Thus, writing ' " ' or '"' would not be identical, since the
latter 
> is an entity and is not expanded at parse-time,
> 
> whereas writing ' " ' or '"' should have the same effect since the 
> latter is a character reference and thus should be expanded at 
> parse-time. 

I think you've gotten stuck in some of the stranger language in the XML
1.0 specification.  Parsers 'expand' character references and parsed
entities as part of the parsing process, but merely report their content
rather than treating them as something that was explicitly in the
document.  (There are unparsed entities, left to applications to
process, but that's a whole different category of fun and rarely used.)

This means that:

> Following, this logic if I have a 3 elements in my XML file
> 
> 1) <foo   name="A&quot;B"> ... </foo> 

the name attribute will be reported as having the value A"B

> 2) <foo   name="A&x34;B"> ... </foo> 

the name attribute will again be reported as having the value A"B
> 3) <foo   name="A"B"> ... </foo> 

the parser will report a fatal error because the quote appeared directly
in the attribute without an entity or character reference escaping it.

> the first should be parsed okay while the last two should give me a 
> parser error. However, I find that the first TWO are parsed okay while 
> the third results in a parse error. The SAX parser implementation I am 
> using is CRIMSON.

The parser is correct.

> It is essential for my application to deal with these occurences of 
> unicode character references and entities. Things are getting a bit 
> complicated now that I figured out that the parser does not behave as 
> expected.

If you want to work at that level of lexical detail, you may either want
to write your own parser or pre-process the document using lexical
tools, maybe regular expressions.
-- 
Simon St.Laurent
Ring around the content, a pocket full of brackets
Errors, errors, all fall down!
http://simonstl.com


-------------------------------------------------------
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31
_______________________________________________
List: sax-devel, [email protected]
See:  http://www.saxproject.org/
https://lists.sourceforge.net/lists/listinfo/sax-devel