This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: Oracle / Text
- From: "Steve Muench" <Steve dot Muench at oracle dot com>
- To: <xsl-list at lists dot mulberrytech dot com>
- Date: Fri, 5 Apr 2002 12:30:12 +0200
- Subject: Re: [xsl] Oracle / Text
- References: <OF037A3426.79E46E93-ON86256B91.0073B3AE@mmm.com>
- Reply-to: xsl-list at lists dot mulberrytech dot com
| Byte #: 1 Byte value: 102
| Byte #: 2 Byte value: 111
| Byte #: 3 Byte value: 111
| Byte #: 4 Byte value: 10
OK. I debugged into this.
The 
 in your <xsl:text>
</xsl:text>
gets normalized to 
 by our XMLParser on the
way *in* so the XSLT transformer sees a character
with ascii value 10 and never sees the character
with ascii value 13.
See section 2.11 of the XML 1.0 spec for the reason
I believe we do this.
To simplify the tasks of applications, wherever an
external parsed entity or the literal entity
value of an internal parsed entity contains either
the literal two-character sequence "#xD#xA" or a
standalone literal #xD, an XML processor must pass
to the application the single character #xA. (This
behavior can conveniently be produced by normalizing
all line breaks to #xA on input, before parsing.)
Our SAXParser appears not to do this, since when
I used the "-x oracle.xml.parser.v2.SAXParser" option
to SAXON, it sees the 13 value and outputs it.
__________________________________________________________
Steve Muench - Developer, Product Mgr, Evangelist, Author
Simplify J2EE and EJB Development with BC4J
http://otn.oracle.com/products/jdev/htdocs/j2ee_bc4j.html
Building Oracle XML Apps, www.oreilly.com/catalog/orxmlapp
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list