Re: AW: Entities

[Scott Boag/CAM/Lotus <Sc...@lotus.com>]

> The FormatterToHTML (same goes for the FormatterToXML) just doesn't
> behave as it should!

Nope.  FormatterToHTML and FormatterToXML are being used in both cases.
The fault goes to FormatterToDOM, which needs to implement the
LexicalHandler interface (which I just did).

> In any case, you should set
>
> parser.setFeature("
http://apache.org/xml/features/dom/create-entity-ref-node
> s", false);
> in your code, even though the Xalan-documenation is somewhat misleading
in
> this aspect.

Hmm... I didn't think Xalan docs said anything about this.  Why is it
misleading?  (Note that entity references aren't part of the XSLT data
model... not sure that this matters for our purposes).

> The program doesn't work, if you construct the XSLTProcessor with
>    XSLTProcessor processor = XSLTProcessorFactory.getProcessor();
> That raises an Exception during execution.

The default liaison is meant primarily for stream-in/stream-out.  You
should be able to do stream-in/dom-out when you're using the default
liaison, but I wouldn't be surprised if there were problems. It's a big
to-do item for me to make the liaison choosing mechanism much more
graceful, so the caller doesn't have to worry about it.

-scott

AW: AW: Entities

[Armin Pfarr <ap...@netsurf.de>]

Hi,

> Nope.  FormatterToHTML and FormatterToXML are being used in both cases.
> The fault goes to FormatterToDOM, which needs to implement the
> LexicalHandler interface (which I just did).

Great

> Hmm... I didn't think Xalan docs said anything about this.  Why is it
> misleading?  (Note that entity references aren't part of the XSLT data
> model... not sure that this matters for our purposes).

If you take a look at features.html in the Xalan-Distribution. Here it is
stated, that setting this parameter to false results in "Do not create
EntityReference nodes in the DOM tree". That was a bit misleading for me.

> (Note that entity references aren't part of the XSLT data
> model... not sure that this matters for our purposes).

Here you mix up two different things:

I was talking about entity-references in the underlying XML-file. The way
they work is defined in the XML-spec.

If you are talking about entity-references in the XSL-stylesheet: I also
don't know how to include entities in this file, since all the XSL-samples
I've seen so far do not include a doctype and can therefore not handle
external entities.

I suppose for building an XSL-parser that means, that you should only check
for well-formedness of the xsl-file and just leave anything in the file as
you got it from the inputstream. Instead I suppose you do a
character-translation of the xsl-file in Xalan.

I didn't find any way to produce the expected output when using a statement
like

<xsl:template match="test">
	<p>ÄÖÜäöü</p>
	<xsl:apply-templates/>
</xsl:template>

Since there is no construct in XSLT (at least as far as I know), that
enables the inclusion of "special"-characters, I just can't produce the
Latin-1 characters for generated text with Xalan. That works fine with XT.

By the way
<xsl:template match="test">
	<p>&#228;</p>
	<xsl:apply-templates/>
</xsl:template>

also doesn't work, even though that is a valid Unicode


Armin

RE: AW: Entities

[Scott Priddy <sp...@Globeset.com>]

I was having the same issues last week when trying to do dom-in/stream-out.
The default liaison (DTMLiaison) would throw exception. Switching to it's
parent class XercesLiaison did the trick.

Scott Priddy

> > The program doesn't work, if you construct the XSLTProcessor with
> >    XSLTProcessor processor = XSLTProcessorFactory.getProcessor();
> > That raises an Exception during execution.
>
> The default liaison is meant primarily for stream-in/stream-out.  You
> should be able to do stream-in/dom-out when you're using the default
> liaison, but I wouldn't be surprised if there were problems.
> It's a big
> to-do item for me to make the liaison choosing mechanism much more
> graceful, so the caller doesn't have to worry about it.
>
> -scott
>
>
>
>