XSLT XHTML MIX DOCTYPE PROBLEM

T

Tjerk Wolterink

Hello i've an xsl stylesheet that must support xhtml entities,
my solution:
----

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE xsl:stylesheet [
<!ENTITY % xhtml PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
%xhtml;
]>

<xsl:stylesheet version="1.0"
xmlns="http://www.w3.org/1999/xhtml"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:page="http://www.wolterinkwebdesign.com/xml/page"
xmlns:form="http://www.wolterinkwebdesign.com/xml/form">

<xsl:include href="xsl/xhtml/standard.xsl"/>
<xsl:eek:utput method="xml" indent="yes"/>

<xsl:param name="absolute_url"/>
<xsl:param name="upload_url"/>
<xsl:variable name="help_icon" select="concat($absolute_url, '/img/help_icon.gif')"/>
<xsl:variable name="error_icon" select="concat($absolute_url, '/img/error.gif')"/>
<xsl:variable name="max_file_size" select="2000000 "/>
<xsl:variable name="max_image_width" select="260"/>

<xsl:template match="/form:form">
<page:page type="module">
<form enctype="multipart/form-data" action="" method="post">
<input type="hidden" name="_xcm_module" value="{@module}" />
---- xsl file is longer


But when i edit this file in my xml-editor it complains that every <xsl: element must be declared.
For example:
Element type "xsl:include" must be declared.

I know what the problem is (i changed the doctype of xsl:stylesheet)
but i dont know the solution!

Please help.
 
D

David Carlisle

Hello i've an xsl stylesheet that must support xhtml entities,
my solution:

why must it use these entities?

whether you use & # 1 6 0 ; or & n b s p ; within the stylesheet never
makes any difference to the result.

So you (and the processor) will have a simpler job if you used numeric
character references (or just use the characters directly) rather than
loading up the XHTML DTD.

If you really want to use the DTD then you will need a parser that reads
an external DTD entity but does not validate. Most parsers will do this
but they may need a special configurartion option. Some parsers default
to validating mode if the file starts with a DOCTYPE and you never want
that for XSLT (as you found:)

If you say which system you are using someone may be able to tell you
what processor specific thing you need to do to turn off validation, but
as I say above you can avoid the entire problem by not using a DOCTYPE
in the stylesheet.

David
 
T

Tjerk Wolterink

David said:
why must it use these entities?

Because i want the xsl to output xhtml, if you know what i mean.
whether you use & # 1 6 0 ; or & n b s p ; within the stylesheet never
makes any difference to the result.

ok but i like to use &nbsp;
So you (and the processor) will have a simpler job if you used numeric
character references (or just use the characters directly) rather than
loading up the XHTML DTD.

The WYSIWYG Xhtml editor that is embedded in my webpages output xhtml with &nbsp;
So &nbsp; spaces must be supported.
If you really want to use the DTD then you will need a parser that reads
an external DTD entity but does not validate. Most parsers will do this
but they may need a special configurartion option. Some parsers default
to validating mode if the file starts with a DOCTYPE and you never want
that for XSLT (as you found:)

Is there no other way?
I just want a valid xsl file that support &nbsp;
If you say which system you are using someone may be able to tell you
what processor specific thing you need to do to turn off validation, but
as I say above you can avoid the entire problem by not using a DOCTYPE
in the stylesheet.

But i want to use &nbsp; so the doctype must be included,
in the webapp i use sablatron, sablatron does not complain (IF i use the doctype xhtml entity defeinitions)
But in my editor (a java based editor) it does complain.

So is there a solution to my problem?

Tjerk
 
S

Stanimir Stamenkov

If you really want to use the DTD then you will need a parser that reads
Is there no other way?
I just want a valid xsl file that support &nbsp;

I've noticed that the transformer I use (that would be the one found
with the Sun's JRE 1.4.2 distribution) always outputs &nbsp; for
  in the source, using HTML mode. Haven't tried it for XHTML,
though.

So you could check with the documentation of your transformation
library if there's some setting for it... as alternative to
including a DOCTYPE.
 
D

David Carlisle

Tjerk Wolterink said:
Because i want the xsl to output xhtml, if you know what i mean.

No, I don't really know what you mean as using or not entity references
in the stylesheet has no bearing on whether or not they are used in the
result.


ok but i like to use &nbsp;

You are not the only one, but it's a distinctly odd thing to like.
nbsp is no shorter or easier to type than #160 and it's a lot harder to
set things up so that it works.
But i want to use &nbsp; so the doctype must be included,

Yes, if you really must:)
in the webapp i use sablatron, sablatron does not complain (IF i use the doctype xhtml entity defeinitions)
But in my editor (a java based editor) it does complain.

So is there a solution to my problem?

Probably. But as I say it is entirely parser specific, so you'll need to
give a bit more information than "a java based editor" about what the
system is, or at least what XML parser it is using, and then hope that
someone reading this knows how to configure the system not to validate.
I'd be very surprised if it wasn't possible, but you have no guarantees,
an XML parser that always validated in the presence of a DOCTYPE is
fully conformant I believe, and if your parser is validating you are
going to get validity errors unless you declare all the elements
and attributes used in the XSL.

David
 
T

Tjerk Wolterink

Stanimir said:
I've noticed that the transformer I use (that would be the one found
with the Sun's JRE 1.4.2 distribution) always outputs &nbsp; for  
in the source, using HTML mode. Haven't tried it for XHTML, though.

So you could check with the documentation of your transformation library
if there's some setting for it... as alternative to including a DOCTYPE.

Ok but the problem is:

i have an xsl file lilke this

<xsl:stylesheet>
<xsl:template name="henk">
<page:section>
<page:header>LAst newsmessage</page:header>
<page:content type="xhtml">
--
some server side scripts gets the edited content from database,
because the content is genereated by a browser-based-text-editor
(http://www.blueshoes.org/en/javascript/editor/) and thus
contains characters like &nbsp;
could convert it with a strreplace($html, "&nbsp;", " ") but
i must then do it for all entities.
So i leave it like &nbsp; IN the stylesheet:
--
</page:content>
</page:section>
</template>
</xsl:stylesheet>


sample result after a page request:

<xsl:stylesheet>
<xsl:template name="henk">
<page:section>
<page:header>LAst newsmessage</page:header>
<page:content type="xhtml">
<!-- editor generated xhtml --!>
<p>
Yes bla <b>yippa</b> &nbsp;

</p>
<!-- end editor generated xhtml --!>
</page:content>
</page:section>
</template>
</xsl:stylesheet>




So using numbers for nbsp is 'impossible'.
 
S

Stanimir Stamenkov

See below (sorry for the long quotation).

/Tjerk Wolterink/:

[...]
some server side scripts gets the edited content from database,
because the content is genereated by a browser-based-text-editor
(http://www.blueshoes.org/en/javascript/editor/) and thus
contains characters like &nbsp;
could convert it with a strreplace($html, "&nbsp;", " ") but
i must then do it for all entities.
So i leave it like &nbsp; IN the stylesheet: [...]

sample result after a page request:

<xsl:stylesheet>
<xsl:template name="henk">
<page:section>
<page:header>LAst newsmessage</page:header>
<page:content type="xhtml">
<!-- editor generated xhtml --!>
<p>
Yes bla <b>yippa</b> &nbsp;

</p>
<!-- end editor generated xhtml --!>
</page:content>
</page:section>
</template>
</xsl:stylesheet>

So using numbers for nbsp is 'impossible'.

Escape the markup as XML text (when read from the DB and supplied as
part of the stylesheet) and use the 'disable-output-escaping':

<xsl:text disable-output-escaping="yes">
&lt;p&gt;
Yes bla &lt;b&gt;yippa&lt;/b&gt; &amp;nbsp;
&lt;/p&gt;
</xsl:text>

This way you can supply pure HTML source (i.e. not well-formed XML),
even.
 
T

Tjerk Wolterink

Stanimir said:
See below (sorry for the long quotation).

/Tjerk Wolterink/:

[...]
some server side scripts gets the edited content from
database,
because the content is genereated by a
browser-based-text-editor
(http://www.blueshoes.org/en/javascript/editor/) and thus
contains characters like &nbsp; could convert
it with a strreplace($html, "&nbsp;", " ") but
i must then do it for all entities.
So i leave it like &nbsp; IN the stylesheet:
[...]


sample result after a page request:

<xsl:stylesheet>
<xsl:template name="henk">
<page:section>
<page:header>LAst newsmessage</page:header>
<page:content type="xhtml">
<!-- editor generated xhtml --!>
<p>
Yes bla <b>yippa</b> &nbsp;
</p>
<!-- end editor generated xhtml --!>
</page:content>
</page:section>
</template>
</xsl:stylesheet>

So using numbers for nbsp is 'impossible'.


Escape the markup as XML text (when read from the DB and supplied as
part of the stylesheet) and use the 'disable-output-escaping':

<xsl:text disable-output-escaping="yes">
&lt;p&gt;
Yes bla &lt;b&gt;yippa&lt;/b&gt; &amp;nbsp;
&lt;/p&gt;
</xsl:text>

This way you can supply pure HTML source (i.e. not well-formed XML), even.

this is a solution,
but id like to treat the genereated xhtml as xml.

But anyways thanks for your input;.
 
S

Stanimir Stamenkov

/Tjerk Wolterink/:
this is a solution,
but id like to treat the genereated xhtml as xml.

I didn't quite get - did you try configuring your parser as David
Carlisle already suggested in previous replies?
 
H

Henri Sivonen

Stanimir Stamenkov said:
Escape the markup as XML text (when read from the DB and supplied as
part of the stylesheet) and use the 'disable-output-escaping':

<xsl:text disable-output-escaping="yes">
&lt;p&gt;
Yes bla &lt;b&gt;yippa&lt;/b&gt; &amp;nbsp;
&lt;/p&gt;
</xsl:text>

That's not a good idea. It defeats one of the advantages of XSLT (the
guarantee of well-formed output) and does not work in tree-to-tree
transformations.
 
S

Stanimir Stamenkov

/Henri Sivonen/:(self spell correction) ^^^^^^^^
XML character data
That's not a good idea. It defeats one of the advantages of XSLT (the
guarantee of well-formed output) and does not work in tree-to-tree
transformations.

I admit - it is not a good idea. Probably the best solution for the
OP would be to do an identity transform (where all entities to be
expanded) on the submitted source prior storing it, which would
check the data for well-formedness at the same time, too. I think it
would be too late to report well-formedness errors when the data is
to be supplied to third-parties (in this case as part of another
document composed with an XSLT sheet).

Still, the copy transformation would require a parser configured to
read the external entities supplied by a DTD, through added DOCTYPE
to the source submitted data, and not to validate... but thinking
more, should the following work?

-----"generated source"

<?xml version="1.0" ?>
<!DOCTYPE xhtml-fragment [

<!ENTITY % xhtml PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
%xhtml;

<!ELEMENT xhtml-fragment ANY>

]>

<xhtml-fragment>
<!-- insert the submitted data here -->
</xhtml-fragment>

-----"generated source"--
 
T

Tjerk Wolterink

Stanimir said:
/Tjerk Wolterink/:



I didn't quite get - did you try configuring your parser as David
Carlisle already suggested in previous replies?

You suggested to use the html-data like this:

<xsl:text disable-output-escaping="yes">
&lt;p&gt;
Yes bla &lt;b&gt;yippa&lt;/b&gt; &amp;nbsp;
&lt;/p&gt;
</xsl:text>


Well i dont want to have that, because now i dont know wether if the xhtml tags are valid (non overlapping <a><b></a></b> and stuff )

So i want to tread the editor-generated xhtml as xhtrml and not as xsl:text.
 
T

Tjerk Wolterink

Stanimir said:
/Henri Sivonen/:



I admit - it is not a good idea. Probably the best solution for the OP
would be to do an identity transform (where all entities to be expanded)
on the submitted source prior storing it, which would check the data for
well-formedness at the same time, too. I think it would be too late to
report well-formedness errors when the data is to be supplied to
third-parties (in this case as part of another document composed with an
XSLT sheet).

The editor says is generated well-formed xhtml. So i take that for granted.
The only problem are the entities like &nbsp;
Still, the copy transformation would require a parser configured to read
the external entities supplied by a DTD, through added DOCTYPE to the
source submitted data, and not to validate... but thinking more, should
the following work?

-----"generated source"

<?xml version="1.0" ?>
<!DOCTYPE xhtml-fragment [

<!ENTITY % xhtml PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
%xhtml;

<!ELEMENT xhtml-fragment ANY>

]>

<xhtml-fragment>
<!-- insert the submitted data here -->
</xhtml-fragment>


Yes but how do i use it with xslt?
-
-
-
damn i made a mistake.
The &nbsp; IN the stylesheets are coded by hand, so i could
edit those to Ģ (it was 290 for nbsp right?).
-

So there is no problem after all. :)

Sorry. but anyways thanks for all your help!
It would offcourse be more beatifull to use &nbsp; IN the xsl-styleheet,
but thats not a real problem.
 
D

David Carlisle

damn i made a mistake.
The &nbsp; IN the stylesheets are coded by hand, so i could
edit those to Ģ (it was 290 for nbsp right?).


160

David
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,755
Messages
2,569,536
Members
45,009
Latest member
GidgetGamb

Latest Threads

Top