You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Andy Parker <an...@virtualtek.com> on 2000/10/17 01:14:18 UTC
HTML inside XML
I've been reading through the archives in order to see if
this question has been answered before, but I haven't been
able to find it, so here goes.
I'm trying to get an XSP page to display the contents of an
email message. The problem occurs when the email isn't in
just a normal plain text form. If the email is in HTML I
can't get it to send the HTML out to the requesting client
without altering the HTML.
I've tried:
<xsp:expr>message.getContent()</xsp:expr>
But then it converts all < and > to < and >
So then I saw someone suggest using util:include-expr, which
I tried and gave the error unknown function valueOf(or
something like that).
So then I tried something with parsing the
message.getContent string into nodes and inserting them into
the document. I don't remember the code for that but it was
covered in a thread in the archives. This caused the XML
parser to complain that META needs to be closed. Of course,
HTML usualy isn't valid XML so it won't work this way.
I've also tried inserting a CDATA section into the document
with the createCDATASection function of
org.apache.xerces.dom.Document class. This does the same
things as the <xsp:expr> one.
I looked into the util taglib and saw util:expr, and decided
why not? what can it hurt. So I tried that:
<util:expr>message.getContent()</util:expr>
which outputs
message.getContent()
So does anyone have any suggestion how I can, in essence,
pass some data within the document all the way out without
the XML parser(Xerces) trying to parse it?
Thanks for listening to my rambling,
Andrew Parker
RE: New ESQL changes...
Posted by Donald Ball <ba...@webslingerZ.com>.
On Thu, 26 Oct 2000, Jeremy Quinn wrote:
> At 13:00 -0400 17/10/00, Donald Ball wrote:
> >On Tue, 17 Oct 2000, Per Kreipke wrote:
> >
> >> Speaking of schemas, the xspdoc namespace you've added to the taglib is
> >> handy. I've written a script to document your esql.xsl taglib without using
> >> stylebook (a limitation you mentioned earlier). Similar to the stylesheet
> >> you mention, but executable using Cocoon itself.
>
> >if you have suggestions for expanding (or explicitly defining!) the xspdoc
> >schema, i'm all ears.
>
> I added these:
>
> Namespace
> <xspdoc:ns>http://www.apache.org/cocoon/XSP/Mailer/1.0</xspdoc:ns>
>
> External package requirements
> <xspdoc:requires>
> <xspdoc:desc>Sun's JavaMail Package</xspdoc:desc>
> <xspdoc:file>mail.jar</xspdoc:file>
> <xspdoc:uri>http://blah.blah/blah</xspdoc:uri>
> </xspdoc:requires>
>
> I would also suggest adding something like the following.
>
> <xspdoc:children>
> <xspdoc:child multiple="true">splish</xspdoc:child>
> <xspdoc:child>splosh</xspdoc:child>
> <xspdoc:children>
>
> To simply document the legal child elements of any tag.
interesting, but do you worry that this is getting too close to being an
actual xml schema? should we look into integrating xspdoc into
that?
- donald
RE: New ESQL changes...
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 13:00 -0400 17/10/00, Donald Ball wrote:
>On Tue, 17 Oct 2000, Per Kreipke wrote:
>
>> Speaking of schemas, the xspdoc namespace you've added to the taglib is
>> handy. I've written a script to document your esql.xsl taglib without using
>> stylebook (a limitation you mentioned earlier). Similar to the stylesheet
>> you mention, but executable using Cocoon itself.
>if you have suggestions for expanding (or explicitly defining!) the xspdoc
>schema, i'm all ears.
I added these:
Namespace
<xspdoc:ns>http://www.apache.org/cocoon/XSP/Mailer/1.0</xspdoc:ns>
External package requirements
<xspdoc:requires>
<xspdoc:desc>Sun's JavaMail Package</xspdoc:desc>
<xspdoc:file>mail.jar</xspdoc:file>
<xspdoc:uri>http://blah.blah/blah</xspdoc:uri>
</xspdoc:requires>
I would also suggest adding something like the following.
<xspdoc:children>
<xspdoc:child multiple="true">splish</xspdoc:child>
<xspdoc:child>splosh</xspdoc:child>
<xspdoc:children>
To simply document the legal child elements of any tag.
>good idea with the args element. thought though - how do you distinguish
>between arguments passed as attributes and arguments passed as elements?
There appears to be a general rule whereby the "config" elements of a Tag
can be either Attributes or child elements.
ie.
<blob:thing shape="amorphous"/>
or
<blob:thing>
<blob:shape>amorphous</blob:shape>
</blob:thing>
So what is the difference between a "child element" and a "config element"?
I think a distinction could be made between an element that merely adds
(dynamic) configuration to a Tag, but could otherwise be an Attribute; and
Tags that are Tags in their own right and are allowed to be nested inside
their "brothers". The "multiple" attribute would signify that it made sense
to have multiple nested elements of that name.
regards Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@sms.genie.co.uk>
RE: New ESQL changes...
Posted by Per Kreipke <pe...@onclave.com>.
> > Speaking of schemas, the xspdoc namespace you've added to the taglib is
> > handy. I've written a script to document your esql.xsl taglib
> without using
> > stylebook (a limitation you mentioned earlier). Similar to the
> stylesheet
> > you mention, but executable using Cocoon itself.
>
> sweet.
>
> > However, what is the full set of tags for that namespace? I
> can't find a way
> > to search the archives to look for the past posts on "xspdoc"
> and "xsp doc"
> > you mentioned in another email.
>
> er, um... i wonder what the subject line was... in any case, the schema
> was never really carved out, everyone just agreed that it was a pretty
> good idea and that you wouldn't run into trouble as long as the xspdoc
> elements appeared as children of xsl:stylesheet.
>
> if you have suggestions for expanding (or explicitly defining!) the xspdoc
> schema, i'm all ears.
Ok. Did that as described below.
> > For myself, I've annotated an earlier version of esql.xsl as
> below and I'd
> > be glad to annotate the current esql (or other) taglibs with
> more detail:
> >
> > <xspdoc:desc>
> > returns the value of the given column as a date. if a
> format attribute
> > exists, its value is taken to be a date format string as defined in
> > java.text.SimpleDateFormat, and the result is formatted accordingly.
> > </xspdoc:desc>
> > <xspdoc:args>
> > <xspdoc:arg name="format">
> > optional formatting value passed directly to 'SimpleDataFormat'
> > </xspdoc:arg>
> > </xspdoc:args>
> > <xsl:template match="esql:results//esql:get-date">
> > ...
> > </xsl:template>
>
> good idea with the args element. thought though - how do you distinguish
> between arguments passed as attributes and arguments passed as elements?
Hmmm. Thought that it was a Cocoon design pattern to always allow either
(can't remember who said this, Ricardo maybe?) so I assumed that an arg was
just an arg. How about
<xspdoc:arg name="xxx" type="attribute|element|both">blah blah</xspdoc:arg>
You'll see in my code that I actually tried to capture a lot of the
different ways that the pattern was expressed when run against the old
taglibs. You found a new way to express that pattern in esql.xsl, so they no
longer work. Of course, they're not necessary either. So, if not declared
explicitly as above, could auto-discover them.
> i'd love it if you sent me the annotated esql logicsheet and the script to
> generate the docs. wonder if anyone would be interested in annotating the
> other logicsheets?
Will do. Was just futzing with it to fix the business described above and
broke it. Give me 5 to fix it again.
Per.
RE: New ESQL changes...
Posted by Per Kreipke <pe...@onclave.com>.
> > 4. I think there's an error in the (old) esql.xsl I've
> attached. According
> > to the XSLT spec, you can't have a <xsl:template> element have both a
> > 'match' and 'name' element. I could be wrong. It's the following match:
> >
> > <xsl:template match="esql:results//esql:get-string" name="get-string">
>
> erm, i think you're wrong. from the xslt spec:
>
> If an xsl:template element has a name attribute, it may, but need not,
> also have a match attribute. (http://www.w3.org/TR/xslt#named-templates)
Corrected, it's pretty explicit :-). Hmm, wonder where I got that from.
Sigh, too much info.
> i'll mull over your xspdoc suggestions and get back with my thoughts
> later. looks pretty good tho.
Ok.
I'm wondering about using nesting:
<xspdoc:func>
<xspdoc:desc>
blah blah
</xspdoc:desc>
<xspdoc:args>
<xspdoc:arg name="arg1" optional="true"
type="attribute|element|either">
optional arg1 blah blah
</xspdoc:arg>
</xspdoc:args>
</xspdoc:func>
Using nesting does removes the dependency on relative position but maybe
it's not as simple or elegant as simply <xspdoc:desc>.
Alternative:
<xspdoc:desc>
blah blah description
<xspdoc:args>
<xspdoc:arg name="arg1" optional="true"
type="attribute|element|either">
optional arg1 blah blah
</xspdoc:arg>
</xspdoc:args>
</xspdoc:desc>
Is there value in simply using <xspdoc:desc> to comment any XML (not just
taglibs) in a way that makes the comments extractable?
I could see using it to comment my actual XML or XSP source files without
necessarily defining functions (e.g. <xspdoc:func>). Maybe one could
define<xspdoc:comment> instead.
Or, how about <xspdoc:buggy>? And <xspdoc:revisit> and <xspdoc:slow>? :-)
Per
RE: New ESQL changes...
Posted by Donald Ball <ba...@webslingerZ.com>.
On Tue, 17 Oct 2000, Per Kreipke wrote:
> 4. I think there's an error in the (old) esql.xsl I've attached. According
> to the XSLT spec, you can't have a <xsl:template> element have both a
> 'match' and 'name' element. I could be wrong. It's the following match:
>
> <xsl:template match="esql:results//esql:get-string" name="get-string">
erm, i think you're wrong. from the xslt spec:
If an xsl:template element has a name attribute, it may, but need not,
also have a match attribute. (http://www.w3.org/TR/xslt#named-templates)
i'll mull over your xspdoc suggestions and get back with my thoughts
later. looks pretty good tho.
- donald
RE: New ESQL changes...
Posted by Donald Ball <ba...@webslingerZ.com>.
On Thu, 19 Oct 2000, Per Kreipke wrote:
> Donald,
>
> Further thoughts about xspdoc?
naw, been busy getting ready for apachecon. i think you pretty much nailed
it though - i'm just trying to figure out if there's a (sane) logicsheet
design methodology which would not be amenable to documentation this
way...
- donald
RE: New ESQL changes...
Posted by Per Kreipke <pe...@onclave.com>.
Donald,
Further thoughts about xspdoc?
Per
> -----Original Message-----
> From: Per Kreipke [mailto:per@onclave.com]
> Sent: Tuesday, October 17, 2000 4:42 PM
> To: cocoon-dev@xml.apache.org
> Subject: RE: New ESQL changes...
>
>
> Donald,
>
> This comment of mine earlier was vague, thought I'd be more specific.
>
> > In tagdocs.xsl you'll see I had to tweak your version from
> > skins/../xsp2document.xsl (sp?), it associated xspdoc:desc's to
> the wrong
> > xsl:template items).
>
> In xspdoc2document.xsl, you have:
>
> <xsl:template match="xspdoc:desc">
> <dt><xsl:value-of select="following-sibling::xsl:template/@match"/></dt>
> <dd><xsl:apply-templates select="text()"/></dd>
> </xsl:template>
>
> but <xsl:value-of select="following-sibling::xsl:template/@match"/> will
> match the next xsl:template in the file, not necessarily only the
> one which
> follows immediately after. The following will:
>
> <xsl:apply-templates
> select="following-sibling::xsl:template[position() = 1]/@match"/>
>
>
> Per.
>
>
RE: New ESQL changes...
Posted by Per Kreipke <pe...@onclave.com>.
Donald,
This comment of mine earlier was vague, thought I'd be more specific.
> In tagdocs.xsl you'll see I had to tweak your version from
> skins/../xsp2document.xsl (sp?), it associated xspdoc:desc's to the wrong
> xsl:template items).
In xspdoc2document.xsl, you have:
<xsl:template match="xspdoc:desc">
<dt><xsl:value-of select="following-sibling::xsl:template/@match"/></dt>
<dd><xsl:apply-templates select="text()"/></dd>
</xsl:template>
but <xsl:value-of select="following-sibling::xsl:template/@match"/> will
match the next xsl:template in the file, not necessarily only the one which
follows immediately after. The following will:
<xsl:apply-templates
select="following-sibling::xsl:template[position() = 1]/@match"/>
Per.
RE: New ESQL changes...
Posted by Per Kreipke <pe...@onclave.com>.
Donald,
1. Attached is an old esql.xsl (renamed to avoid conflicts) annotated as I
described in the earlier email.
2. Also attached are tagdocs.xml and tagdocs.xsl. Instructions are at the
top of tagdocs.xml. You'll need to massage the internal 'baseDir' variable.
3. Perhaps it would be better to set up the xspdoc namespace to be more like
I've shown below. I had trouble getting the XSLT expression right to get the
prev and next sibling.
In tagdocs.xsl you'll see I had to tweak your version from
skins/../xsp2document.xsl (sp?), it associated xspdoc:desc's to the wrong
xsl:template items).
<xspdoc:func>
<xspdoc:desc>
<xspdoc:args>
<xspdoc:arg>
</xspdoc:arg>
</xspdoc:args>
</xspdoc:func>
4. I think there's an error in the (old) esql.xsl I've attached. According
to the XSLT spec, you can't have a <xsl:template> element have both a
'match' and 'name' element. I could be wrong. It's the following match:
<xsl:template match="esql:results//esql:get-string" name="get-string">
Per.
> -----Original Message-----
> From: Donald Ball [mailto:balld@webslingerZ.com]
> Sent: Tuesday, October 17, 2000 1:00 PM
> To: cocoon-users@xml.apache.org
> Cc: cocoon-dev@xml.apache.org
> Subject: RE: New ESQL changes...
>
>
> On Tue, 17 Oct 2000, Per Kreipke wrote:
>
> > Speaking of schemas, the xspdoc namespace you've added to the taglib is
> > handy. I've written a script to document your esql.xsl taglib
> without using
> > stylebook (a limitation you mentioned earlier). Similar to the
> stylesheet
> > you mention, but executable using Cocoon itself.
>
> sweet.
>
> > However, what is the full set of tags for that namespace? I
> can't find a way
> > to search the archives to look for the past posts on "xspdoc"
> and "xsp doc"
> > you mentioned in another email.
>
> er, um... i wonder what the subject line was... in any case, the schema
> was never really carved out, everyone just agreed that it was a pretty
> good idea and that you wouldn't run into trouble as long as the xspdoc
> elements appeared as children of xsl:stylesheet.
>
> if you have suggestions for expanding (or explicitly defining!) the xspdoc
> schema, i'm all ears.
>
> > For myself, I've annotated an earlier version of esql.xsl as
> below and I'd
> > be glad to annotate the current esql (or other) taglibs with
> more detail:
> >
> > <xspdoc:desc>
> > returns the value of the given column as a date. if a
> format attribute
> > exists, its value is taken to be a date format string as defined in
> > java.text.SimpleDateFormat, and the result is formatted accordingly.
> > </xspdoc:desc>
> > <xspdoc:args>
> > <xspdoc:arg name="format">
> > optional formatting value passed directly to 'SimpleDataFormat'
> > </xspdoc:arg>
> > </xspdoc:args>
> > <xsl:template match="esql:results//esql:get-date">
> > ...
> > </xsl:template>
>
> good idea with the args element. thought though - how do you distinguish
> between arguments passed as attributes and arguments passed as elements?
>
> i'd love it if you sent me the annotated esql logicsheet and the script to
> generate the docs. wonder if anyone would be interested in annotating the
> other logicsheets?
>
> - donald
>
>
RE: New ESQL changes...
Posted by Donald Ball <ba...@webslingerZ.com>.
On Tue, 17 Oct 2000, Per Kreipke wrote:
> Speaking of schemas, the xspdoc namespace you've added to the taglib is
> handy. I've written a script to document your esql.xsl taglib without using
> stylebook (a limitation you mentioned earlier). Similar to the stylesheet
> you mention, but executable using Cocoon itself.
sweet.
> However, what is the full set of tags for that namespace? I can't find a way
> to search the archives to look for the past posts on "xspdoc" and "xsp doc"
> you mentioned in another email.
er, um... i wonder what the subject line was... in any case, the schema
was never really carved out, everyone just agreed that it was a pretty
good idea and that you wouldn't run into trouble as long as the xspdoc
elements appeared as children of xsl:stylesheet.
if you have suggestions for expanding (or explicitly defining!) the xspdoc
schema, i'm all ears.
> For myself, I've annotated an earlier version of esql.xsl as below and I'd
> be glad to annotate the current esql (or other) taglibs with more detail:
>
> <xspdoc:desc>
> returns the value of the given column as a date. if a format attribute
> exists, its value is taken to be a date format string as defined in
> java.text.SimpleDateFormat, and the result is formatted accordingly.
> </xspdoc:desc>
> <xspdoc:args>
> <xspdoc:arg name="format">
> optional formatting value passed directly to 'SimpleDataFormat'
> </xspdoc:arg>
> </xspdoc:args>
> <xsl:template match="esql:results//esql:get-date">
> ...
> </xsl:template>
good idea with the args element. thought though - how do you distinguish
between arguments passed as attributes and arguments passed as elements?
i'd love it if you sent me the annotated esql logicsheet and the script to
generate the docs. wonder if anyone would be interested in annotating the
other logicsheets?
- donald
RE: New ESQL changes...
Posted by Donald Ball <ba...@webslingerZ.com>.
On Tue, 17 Oct 2000, Per Kreipke wrote:
> Speaking of schemas, the xspdoc namespace you've added to the taglib is
> handy. I've written a script to document your esql.xsl taglib without using
> stylebook (a limitation you mentioned earlier). Similar to the stylesheet
> you mention, but executable using Cocoon itself.
sweet.
> However, what is the full set of tags for that namespace? I can't find a way
> to search the archives to look for the past posts on "xspdoc" and "xsp doc"
> you mentioned in another email.
er, um... i wonder what the subject line was... in any case, the schema
was never really carved out, everyone just agreed that it was a pretty
good idea and that you wouldn't run into trouble as long as the xspdoc
elements appeared as children of xsl:stylesheet.
if you have suggestions for expanding (or explicitly defining!) the xspdoc
schema, i'm all ears.
> For myself, I've annotated an earlier version of esql.xsl as below and I'd
> be glad to annotate the current esql (or other) taglibs with more detail:
>
> <xspdoc:desc>
> returns the value of the given column as a date. if a format attribute
> exists, its value is taken to be a date format string as defined in
> java.text.SimpleDateFormat, and the result is formatted accordingly.
> </xspdoc:desc>
> <xspdoc:args>
> <xspdoc:arg name="format">
> optional formatting value passed directly to 'SimpleDataFormat'
> </xspdoc:arg>
> </xspdoc:args>
> <xsl:template match="esql:results//esql:get-date">
> ...
> </xsl:template>
good idea with the args element. thought though - how do you distinguish
between arguments passed as attributes and arguments passed as elements?
i'd love it if you sent me the annotated esql logicsheet and the script to
generate the docs. wonder if anyone would be interested in annotating the
other logicsheets?
- donald
RE: New ESQL changes...
Posted by Per Kreipke <pe...@onclave.com>.
> > I want to use the new ESQL taglib but I noticed that in the CVS archive,
> > there are only these files:
> >
> > Column.java
> > XSPSQLLibrary.java
> > esql.xsl
> > sql.xsl
> >
> > while my 1.8 source tree has the following:
> >
> > Column.java
> > ColumnFormatter.java
> > ConnectionCreator.java
> > ConnectionDefs.java
> > DefaultQueryCreator.java
> > QueryCreator.java
> > SQLProcessor.java
> > SQLQueryCreator.java
> > Utils.java
> >
> > Can I get rid of everything but the two files now in CVS?
>
> if you just want to use the esql logicsheet, you can lose everything
> except esql.xsl. beware - esql is still undergoing active development, and
> i reserve the right to change the namespace until matt and i carve out the
> official schema (hopefully this weekend!)
No problem.
Speaking of schemas, the xspdoc namespace you've added to the taglib is
handy. I've written a script to document your esql.xsl taglib without using
stylebook (a limitation you mentioned earlier). Similar to the stylesheet
you mention, but executable using Cocoon itself.
However, what is the full set of tags for that namespace? I can't find a way
to search the archives to look for the past posts on "xspdoc" and "xsp doc"
you mentioned in another email.
For myself, I've annotated an earlier version of esql.xsl as below and I'd
be glad to annotate the current esql (or other) taglibs with more detail:
<xspdoc:desc>
returns the value of the given column as a date. if a format attribute
exists, its value is taken to be a date format string as defined in
java.text.SimpleDateFormat, and the result is formatted accordingly.
</xspdoc:desc>
<xspdoc:args>
<xspdoc:arg name="format">
optional formatting value passed directly to 'SimpleDataFormat'
</xspdoc:arg>
</xspdoc:args>
<xsl:template match="esql:results//esql:get-date">
...
</xsl:template>
Per
Re: New ESQL changes...
Posted by Donald Ball <ba...@webslingerZ.com>.
On Tue, 17 Oct 2000, Per Kreipke wrote:
> I want to use the new ESQL taglib but I noticed that in the CVS archive,
> there are only these files:
>
> Column.java
> XSPSQLLibrary.java
> esql.xsl
> sql.xsl
>
> while my 1.8 source tree has the following:
>
> Column.java
> ColumnFormatter.java
> ConnectionCreator.java
> ConnectionDefs.java
> DefaultQueryCreator.java
> QueryCreator.java
> SQLProcessor.java
> SQLQueryCreator.java
> Utils.java
>
> Can I get rid of everything but the two files now in CVS?
if you just want to use the esql logicsheet, you can lose everything
except esql.xsl. beware - esql is still undergoing active development, and
i reserve the right to change the namespace until matt and i carve out the
official schema (hopefully this weekend!)
- donald
New ESQL changes...
Posted by Per Kreipke <pe...@onclave.com>.
I want to use the new ESQL taglib but I noticed that in the CVS archive,
there are only these files:
Column.java
XSPSQLLibrary.java
esql.xsl
sql.xsl
while my 1.8 source tree has the following:
Column.java
ColumnFormatter.java
ConnectionCreator.java
ConnectionDefs.java
DefaultQueryCreator.java
QueryCreator.java
SQLProcessor.java
SQLQueryCreator.java
Utils.java
Can I get rid of everything but the two files now in CVS?
Per.
Re: HTML inside XML
Posted by Jimi Thompson <jt...@link.com>.
I knew there was a way to tell XML NOT to parse......
Donald Ball wrote:
> On Tue, 17 Oct 2000, Per Kreipke wrote:
>
> > You should be able to simply enclose the HTML inside a CDATA section.
> >
> > XML allows marked off portions of text. The sections are marked off with
> > PCDATA (parsed canonical data) or CDATA (unparsed canonical data).
> >
> > Simply surround your text section like this:
> >
> > <![CDATA[
> > your <funky> text here
> > ]]>
>
> nope, it'll be serialized using entities.
>
> - donald
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org
--
Jimi Thompson
Web Master
L3 communications
RE: HTML inside XML
Posted by Per Kreipke <pe...@onclave.com>.
> > > only if that text appears directly in the xml file. if you're
> including it
> > > from a dynamic data source, e.g. with the mail logicsheet, the string
> > > doesn't need to be parsed because it's being added to the DOM
> object (or
> > > SAX stream) programmatically.
> >
> > Ok, I understand how that could be. But downstream, when the
> XSL processor
> > gets it, how can it not be mal-formed?
>
> because the entities only need to be escaped when the xml is serialized as
> text. when the xml is being passed around as a java object(s), it's
> already been parsed so we know that a < appearing in a text node is, in
> fact, a < character, not an element indicator.
Hmmm. That sounds like it'd be true if the internal representation is a DOM
object and the XSL processor didn't have to reparse it. I guess that's how
C1 works?
In C2, when everything is SAX based, wouldn't each processor in the chain
have to re-stream its input in order to 'fire' SAX events?
Per.
RE: HTML inside XML
Posted by Donald Ball <ba...@webslingerZ.com>.
On Tue, 17 Oct 2000, Per Kreipke wrote:
> > only if that text appears directly in the xml file. if you're including it
> > from a dynamic data source, e.g. with the mail logicsheet, the string
> > doesn't need to be parsed because it's being added to the DOM object (or
> > SAX stream) programmatically.
>
> Ok, I understand how that could be. But downstream, when the XSL processor
> gets it, how can it not be mal-formed?
because the entities only need to be escaped when the xml is serialized as
text. when the xml is being passed around as a java object(s), it's
already been parsed so we know that a < appearing in a text node is, in
fact, a < character, not an element indicator.
- donald
RE: HTML inside XML
Posted by Per Kreipke <pe...@onclave.com>.
> > > > You should be able to simply enclose the HTML inside a
> CDATA section.
> > > >
> > > > XML allows marked off portions of text. The sections are
> marked off with
> > > > PCDATA (parsed canonical data) or CDATA (unparsed canonical data).
> > > >
> > > > Simply surround your text section like this:
> > > >
> > > > <![CDATA[
> > > > your <funky> text here
> > > > ]]>
> > >
> > > nope, it'll be serialized using entities.
> >
> > True, I didn't pay attention to his intent. You (and Robin) are
> saying that
> > any markup content that isn't also well-formed can't be run
> though Cocoon.
> >
> > As an aside, for content without markup, wouldn't one need
> CDATA sections to
> > fix emails like below?
> >
> > "If Bill & Bob want to meet on sunday, that's great."
>
> only if that text appears directly in the xml file. if you're including it
> from a dynamic data source, e.g. with the mail logicsheet, the string
> doesn't need to be parsed because it's being added to the DOM object (or
> SAX stream) programmatically.
Ok, I understand how that could be. But downstream, when the XSL processor
gets it, how can it not be mal-formed?
Per.
RE: HTML inside XML
Posted by Donald Ball <ba...@webslingerZ.com>.
On Tue, 17 Oct 2000, Per Kreipke wrote:
> > > You should be able to simply enclose the HTML inside a CDATA section.
> > >
> > > XML allows marked off portions of text. The sections are marked off with
> > > PCDATA (parsed canonical data) or CDATA (unparsed canonical data).
> > >
> > > Simply surround your text section like this:
> > >
> > > <![CDATA[
> > > your <funky> text here
> > > ]]>
> >
> > nope, it'll be serialized using entities.
>
> True, I didn't pay attention to his intent. You (and Robin) are saying that
> any markup content that isn't also well-formed can't be run though Cocoon.
>
> As an aside, for content without markup, wouldn't one need CDATA sections to
> fix emails like below?
>
> "If Bill & Bob want to meet on sunday, that's great."
only if that text appears directly in the xml file. if you're including it
from a dynamic data source, e.g. with the mail logicsheet, the string
doesn't need to be parsed because it's being added to the DOM object (or
SAX stream) programmatically.
- donald
RE: HTML inside XML
Posted by Per Kreipke <pe...@onclave.com>.
> > You should be able to simply enclose the HTML inside a CDATA section.
> >
> > XML allows marked off portions of text. The sections are marked off with
> > PCDATA (parsed canonical data) or CDATA (unparsed canonical data).
> >
> > Simply surround your text section like this:
> >
> > <![CDATA[
> > your <funky> text here
> > ]]>
>
> nope, it'll be serialized using entities.
True, I didn't pay attention to his intent. You (and Robin) are saying that
any markup content that isn't also well-formed can't be run though Cocoon.
As an aside, for content without markup, wouldn't one need CDATA sections to
fix emails like below?
"If Bill & Bob want to meet on sunday, that's great."
Per.
RE: HTML inside XML
Posted by Donald Ball <ba...@webslingerZ.com>.
On Tue, 17 Oct 2000, Per Kreipke wrote:
> You should be able to simply enclose the HTML inside a CDATA section.
>
> XML allows marked off portions of text. The sections are marked off with
> PCDATA (parsed canonical data) or CDATA (unparsed canonical data).
>
> Simply surround your text section like this:
>
> <![CDATA[
> your <funky> text here
> ]]>
nope, it'll be serialized using entities.
- donald
RE: HTML inside XML
Posted by Per Kreipke <pe...@onclave.com>.
You should be able to simply enclose the HTML inside a CDATA section.
XML allows marked off portions of text. The sections are marked off with
PCDATA (parsed canonical data) or CDATA (unparsed canonical data).
Simply surround your text section like this:
<![CDATA[
your <funky> text here
]]>
Per.
> -----Original Message-----
> From: Jimi Thompson [mailto:jthompson@link.com]
> Sent: Monday, October 16, 2000 7:23 PM
> To: cocoon-users@xml.apache.org
> Subject: Re: HTML inside XML
>
>
> Andy,
>
> I'm new at this myself, so that may well be the blind leading the blind,
> but there is a way to turn off parsing for a portion of the document,
> which I think will solve your problem. You DON'T want the email parsed
> (if I am understanding this correctly). I will try to find out what it
> is, but I think I saw a note about it in the W3C specs. Until I can
> locate this and see if it applies to you, you might try looking at
> XML.org because I think I might have see that there too.
>
> Sorry I'm not more help,
>
> Jimi
>
> Andy Parker wrote:
>
> > I've been reading through the archives in order to see if
> > this question has been answered before, but I haven't been
> > able to find it, so here goes.
> >
> > I'm trying to get an XSP page to display the contents of an
> > email message. The problem occurs when the email isn't in
> > just a normal plain text form. If the email is in HTML I
> > can't get it to send the HTML out to the requesting client
> > without altering the HTML.
> >
> > I've tried:
> >
> > <xsp:expr>message.getContent()</xsp:expr>
> >
> > But then it converts all < and > to < and >
> >
> > So then I saw someone suggest using util:include-expr, which
> > I tried and gave the error unknown function valueOf(or
> > something like that).
> >
> > So then I tried something with parsing the
> > message.getContent string into nodes and inserting them into
> > the document. I don't remember the code for that but it was
> > covered in a thread in the archives. This caused the XML
> > parser to complain that META needs to be closed. Of course,
> > HTML usualy isn't valid XML so it won't work this way.
> >
> > I've also tried inserting a CDATA section into the document
> > with the createCDATASection function of
> > org.apache.xerces.dom.Document class. This does the same
> > things as the <xsp:expr> one.
> >
> > I looked into the util taglib and saw util:expr, and decided
> > why not? what can it hurt. So I tried that:
> >
> > <util:expr>message.getContent()</util:expr>
> >
> > which outputs
> >
> > message.getContent()
> >
> > So does anyone have any suggestion how I can, in essence,
> > pass some data within the document all the way out without
> > the XML parser(Xerces) trying to parse it?
> >
> > Thanks for listening to my rambling,
> > Andrew Parker
>
> --
> Jimi Thompson
> Web Master
> L3 communications
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org
>
>
Re: HTML inside XML
Posted by Jimi Thompson <jt...@link.com>.
Andy,
I'm new at this myself, so that may well be the blind leading the blind,
but there is a way to turn off parsing for a portion of the document,
which I think will solve your problem. You DON'T want the email parsed
(if I am understanding this correctly). I will try to find out what it
is, but I think I saw a note about it in the W3C specs. Until I can
locate this and see if it applies to you, you might try looking at
XML.org because I think I might have see that there too.
Sorry I'm not more help,
Jimi
Andy Parker wrote:
> I've been reading through the archives in order to see if
> this question has been answered before, but I haven't been
> able to find it, so here goes.
>
> I'm trying to get an XSP page to display the contents of an
> email message. The problem occurs when the email isn't in
> just a normal plain text form. If the email is in HTML I
> can't get it to send the HTML out to the requesting client
> without altering the HTML.
>
> I've tried:
>
> <xsp:expr>message.getContent()</xsp:expr>
>
> But then it converts all < and > to < and >
>
> So then I saw someone suggest using util:include-expr, which
> I tried and gave the error unknown function valueOf(or
> something like that).
>
> So then I tried something with parsing the
> message.getContent string into nodes and inserting them into
> the document. I don't remember the code for that but it was
> covered in a thread in the archives. This caused the XML
> parser to complain that META needs to be closed. Of course,
> HTML usualy isn't valid XML so it won't work this way.
>
> I've also tried inserting a CDATA section into the document
> with the createCDATASection function of
> org.apache.xerces.dom.Document class. This does the same
> things as the <xsp:expr> one.
>
> I looked into the util taglib and saw util:expr, and decided
> why not? what can it hurt. So I tried that:
>
> <util:expr>message.getContent()</util:expr>
>
> which outputs
>
> message.getContent()
>
> So does anyone have any suggestion how I can, in essence,
> pass some data within the document all the way out without
> the XML parser(Xerces) trying to parse it?
>
> Thanks for listening to my rambling,
> Andrew Parker
--
Jimi Thompson
Web Master
L3 communications