By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
439,978 Members | 1,373 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 439,978 IT Pros & Developers. It's quick & easy.

XSLT XHTML MIX DOCTYPE PROBLEM

P: n/a
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:output 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.
Jul 20 '05 #1
Share this Question
Share on Google+
13 Replies


P: n/a

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

Jul 20 '05 #2

P: n/a
David Carlisle wrote:
Hello i've an xsl stylesheet that must support xhtml entities,
my solution:

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?
David


Tjerk

Jul 20 '05 #3

P: n/a
>> 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;


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.

--
Stanimir

P.S.: And please, DON'T use all capital letters in the subject, next
time.
Jul 20 '05 #4

P: n/a
Tjerk Wolterink <tj***@wolterinkwebdesign.com> writes:
David Carlisle wrote:
Hello i've an xsl stylesheet that must support xhtml entities,
my solution:

why must it use these entities?


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.

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;


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.
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,


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
Jul 20 '05 #5

P: n/a
Stanimir Stamenkov wrote:
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;

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'.
Jul 20 '05 #6

P: n/a
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.

--
Stanimir
Jul 20 '05 #7

P: n/a
Stanimir Stamenkov wrote:
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;.
Jul 20 '05 #8

P: n/a
/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?

--
Stanimir
Jul 20 '05 #9

P: n/a
In article <37*************@individual.net>,
Stanimir Stamenkov <s7****@netscape.net> wrote:
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.

--
Henri Sivonen
hs******@iki.fi
http://iki.fi/hsivonen/
Jul 20 '05 #10

P: n/a
/Henri Sivonen/:
In article <37*************@individual.net>,
Stanimir Stamenkov <s7****@netscape.net> wrote:
Escape the markup as XML text (when read from the DB and supplied as (self spell correction) ^^^^^^^^
XML character data
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.


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"--

--
Stanimir
Jul 20 '05 #11

P: n/a
Stanimir Stamenkov wrote:
/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?


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.
Jul 20 '05 #12

P: n/a
Stanimir Stamenkov wrote:
/Henri Sivonen/:
In article <37*************@individual.net>, Stanimir Stamenkov
<s7****@netscape.net> wrote:
Escape the markup as XML text (when read from the DB and supplied as
cut

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).


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.

-----"generated source"--

Jul 20 '05 #13

P: n/a

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
Jul 20 '05 #14

This discussion thread is closed

Replies have been disabled for this discussion.