You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Colin Paul Adams <co...@colina.demon.co.uk> on 2004/06/29 17:39:20 UTC
CForms stylesheets - use of xsl:param and xhtml
The stylesheets in $COCOON_ROOT/src/blocks/samples/resources only
handle html input/output.
I use xhtml exclusively. Whilst I can easily copy the stylesheets to a
private directory, and change them to work with xhtml instead, I would
then have to re-work them every time changes were made to the
distrbuted versions. Also other people would not benefit.
So I thought it would be pretty easy to
change the stylesheets so they could cope with either html or xhtml
input (generating output as html for html input and xhtml as xhtml
output).
In principle, it IS easy, but I have come across two problems.
The first is how to indicate to the stylsheets which format to use.
No problem - just provide a global boolean xsl:param in the driver stylesheet
(forms-samples-styling.xsl), defaulting to false, which can be set in
the sitemap to true, if you want XHTML.
The only problem with this is that is people have created their own
driver stylesheet, then it will lack the parameter, and the
stylesheets won't compile.
But I guess as CForms is not yet stable, this could be acceptable.
Then there is a related problem - basically a bug in the current
stylesheets (but it may be intentional, if their is instead a bug in
Xalan-J - I don't know - I'm guessing).
The problem is that according to the XSLT specification (both 1.0 and
2.0), it is an error to have two global parameters with the same name
in a stylesheet with the same import precedence, unless there is one
with a higher import precedence.
Now, in forms-advanced-field-styling.xsl, there is a global parameter
named resources-uri.
This module xsl:includes forms-calendar-styling.xsl and
forms-htmlarea-styling.xsl both of which re-declare (identically) the
same global parameter. As they are included rather than imported, they
all have the same import precedence.
A possible fix is to include rather than import these two modules -
but maybe there is a good reason why this can't be done (I haven't
looked at them closely enough to determine if include is necessary).
A simpler fix is to remove the declarations from the included
stylesheets - both of them state that they are designed to be included
from forms-advanced-field-styling.xsl, so the global param is
guarenteed to be present.
My only worry about this is that there might be some bug in Xalan-C
that has caused them to be written like this.
presumably there is already a bug in this area with Xalan-C as the
spec indicates that the current stylesheets are in error, and so
should be rejected. Saxon 8 rejects them. Interestingly, xsltproc does
not reject them.
So after all that, if I were to provide patches that:
a) Remove the offending global parameter from the two stylesheets,
b) add a global parameter to the driver stylesheet
c) Add code to all the stylesheets to read either html or xhtml input,
and write output as html or xhtml according to the value of the new
parameter
would these pathces be accepted? (If not, then I don't want to bother,
as it is then easier for me to do a copy-paste-edit cycle)
--
Colin Paul Adams
Preston Lancashire
Re: CForms stylesheets - use of xsl:param and xhtml
Posted by Colin Paul Adams <co...@colina.demon.co.uk>.
>>>>> "Joerg" == Joerg Heinicke <jo...@gmx.de> writes:
Joerg> On 29.06.2004 22:03, Colin Paul Adams wrote:
>> Tomorrow, I'll revert to the HTML serializer, and see how the
>> output validates as HTML (it won't completely, because of the
>> presence of xmlns attributes for the xhtml namespace).
Joerg> Exactly. This is what I did and I fixed some issues:
Joerg> http://marc.theaimsgroup.com/?l=xml-cocoon-cvs&m=108853827329381&w=4
Joerg> http://marc.theaimsgroup.com/?l=xml-cocoon-cvs&m=108853882419530&w=4
After applying your changes to my own changes, I get an NPE:
Original Exception: java.lang.RuntimeException: java.lang.RuntimeException: java.lang.NullPointerException
at org.apache.xalan.transformer.TransformerImpl.run(TransformerImpl.java:3418)
at org.apache.xalan.transformer.TransformerHandlerImpl.endDocument(TransformerHandlerImpl.java:389)
at org.apache.cocoon.xml.AbstractXMLPipe.endDocument(AbstractXMLPipe.java:56)
at org.apache.cocoon.transformation.TraxTransformer.endDocument(TraxTransformer.java:549)
at org.apache.cocoon.xml.AbstractXMLPipe.endDocument(AbstractXMLPipe.java:56)
at org.apache.cocoon.xml.AbstractXMLPipe.endDocument(AbstractXMLPipe.java:56)
at org.apache.cocoon.forms.transformation.EffectPipe$Output.copy(EffectPipe.java:257)
at org.apache.cocoon.forms.transformation.EffectWidgetReplacingPipe$DocHandler.process(EffectWidgetReplacingPipe.java:266)
at org.apache.cocoon.forms.transformation.EffectPipe.endDocument(EffectPipe.java:391)
at org.apache.cocoon.components.sax.XMLTeePipe.endDocument(XMLTeePipe.java:67)
at org.apache.xerces.parsers.AbstractSAXParser.endDocument(Unknown Source)
at org.apache.xerces.impl.XMLDocumentScannerImpl.endEntity(Unknown Source)
at org.apache.xerces.impl.XMLEntityManager.endEntity(Unknown Source)
at org.apache.xerces.impl.XMLEntityScanner.load(Unknown Source)
at org.apache.xerces.impl.XMLEntityScanner.skipSpaces(Unknown Source)
at org.apache.xerces.impl.XMLDocumentScannerImpl$TrailingMiscDispatcher.dispatch(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
The stylesheets are still all well-formed, so i don't know what is
going on.
I guess I shall have to wait until bug #29854 is fixed, then I can
test on my own forms, and get that working first?
Joerg> empty select for the double-listbox. There are no more
Joerg> errors for transitional 4.01 html - expect the whole form
Joerg> model gui sample :)
Why code for the transitional DTD at all? Surely all coding should be
for the strict DTD these days?
--
Colin Paul Adams
Preston Lancashire
Re: CForms stylesheets - use of xsl:param and xhtml
Posted by Joerg Heinicke <jo...@gmx.de>.
On 29.06.2004 22:03, Colin Paul Adams wrote:
> Tomorrow, I'll revert to the HTML serializer, and see how the output
> validates as HTML (it won't completely, because of the presence of
> xmlns attributes for the xhtml namespace).
Exactly. This is what I did and I fixed some issues:
http://marc.theaimsgroup.com/?l=xml-cocoon-cvs&m=108853827329381&w=4
http://marc.theaimsgroup.com/?l=xml-cocoon-cvs&m=108853882419530&w=4
Most of the remaining errors (there are not so many) are because of the
xmlns:fi namespace declaration. Another source of non-validity is a
missing alt attribute for our help.gif. We could easily fix it by adding
a further i18n roundtrip (I would not hardcode it). The third one is an
empty select for the double-listbox. There are no more errors for
transitional 4.01 html - expect the whole form model gui sample :)
Joerg
Re: CForms stylesheets - use of xsl:param and xhtml
Posted by Colin Paul Adams <co...@colina.demon.co.uk>.
>>>>> "Ugo" == Ugo Cei <ug...@apache.org> writes:
Ugo> Il giorno 29/giu/04, alle 19:56, Bruno Dumon ha scritto:
>> I'm not against the introduction of XHTML, but I want HTML to
>> remain supported.
Ugo> Me too. Only I'd rather have XHTML as the default, since it
Ugo> can be converted to HTML by stripping namespaces, which if
Ugo> fairly easy. Or am I missing something obvious?
I don't think so.
I've made what I think are all the necessary changes to the
stylesheets.
At least, they may be all that's necessary for an XHTML 1.0
transitional DTD.
I always use XHTML 1.1 (I like to be up with the times). This of
course is a strict DTD.
Now I tried changing the forms sitemap to use the xhtml11 serializer -
to see how close I can get to checking it all. Since the source is
HTML this certainly won't be valid, but it's a first step at seeing
what else might be wrong.
A large number of attributes are highlighted that correspond to CSS
styling. These have no place in a Strict DTD. I guess the default html
serializer is for the transitional DTD?
Tomorrow, I'll revert to the HTML serializer, and see how the output
validates as HTML (it won't completely, because of the presence of
xmlns attributes for the xhtml namespace).
--
Colin Paul Adams
Preston Lancashire
Re: CForms stylesheets - use of xsl:param and xhtml
Posted by Ugo Cei <ug...@apache.org>.
Il giorno 29/giu/04, alle 19:56, Bruno Dumon ha scritto:
> I'm not against the introduction of XHTML, but I want HTML to remain
> supported.
Me too. Only I'd rather have XHTML as the default, since it can be
converted to HTML by stripping namespaces, which if fairly easy. Or am
I missing something obvious?
Ugo
--
Ugo Cei - http://beblogging.com/
Re: CForms stylesheets - use of xsl:param and xhtml
Posted by Colin Paul Adams <co...@colina.demon.co.uk>.
>>>>> "Bruno" == Bruno Dumon <br...@outerthought.org> writes:
Bruno> I'm not against the introduction of XHTML, but I want HTML
Bruno> to remain supported.
>> If someone wants HTML output, he/she can always add a
>> namespace-stripping transformation and use the HTML serializer
>> afterwards.
>>
>> Ugo
It seems to me that a straight forward solution would be to introduce
a boolean parameter for the HTML serializer, and make it the default, to strip
any xmlns="http://www.w3.org/1999/xhtml" namespace nodes.
Then compatibility is maintained, but if for some reason you DID want
these attributes to appear, you could set the parameter to false.
--
Colin Paul Adams
Preston Lancashire
Re: CForms stylesheets - use of xsl:param and xhtml
Posted by Bruno Dumon <br...@outerthought.org>.
On Tue, 2004-06-29 at 19:10, Ugo Cei wrote:
> Colin Paul Adams wrote:
>
> > xhtml elements are in a namespace - html elements are not.
>
> Oh yes. Then I'd rather have the CForms stylesheet output XHTML by
> default.
Why? I certainly wouldn't. To be any practical, this would mean all
HTML-related things should be changed to XHTML, thus also the form
templates, other files you are merging, output of other XSLT transforms,
etc. Otherwise you'll get a mix of namespaced and non-namespaced HTML.
If from the start you decide to make an all-XHTML system, then this is
all very feasible, but I'd rather not be forced to make the switch to
XHTML now, nor do I want to strip the namespace afterwards.
I'm not against the introduction of XHTML, but I want HTML to remain
supported.
> If someone wants HTML output, he/she can always add a
> namespace-stripping transformation and use the HTML serializer afterwards.
>
> Ugo
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
Re: CForms stylesheets - use of xsl:param and xhtml
Posted by Ugo Cei <u....@cbim.it>.
Colin Paul Adams wrote:
> xhtml elements are in a namespace - html elements are not.
Oh yes. Then I'd rather have the CForms stylesheet output XHTML by
default. If someone wants HTML output, he/she can always add a
namespace-stripping transformation and use the HTML serializer afterwards.
Ugo
Re: CForms stylesheets - use of xsl:param and xhtml
Posted by Colin Paul Adams <co...@colina.demon.co.uk>.
>>>>> "Ugo" == Ugo Cei <u....@cbim.it> writes:
Ugo> Colin Paul Adams wrote:
Ugo> I don't understand what's the difference between html and
Ugo> xhtml in this respect. Can you elaborate further? The output
Ugo> from the XSL-T transformation should be well-formed XML in
Ugo> any case, it cannot be traditional HTML.
xhtml elements are in a namespace - html elements are not.
Ugo> Please do provide them.
Will do.
--
Colin Paul Adams
Preston Lancashire
Re: CForms stylesheets - use of xsl:param and xhtml
Posted by Ugo Cei <u....@cbim.it>.
Colin Paul Adams wrote:
> So after all that, if I were to provide patches that:
> a) Remove the offending global parameter from the two stylesheets,
+ 1
> b) add a global parameter to the driver stylesheet
> c) Add code to all the stylesheets to read either html or xhtml input,
> and write output as html or xhtml according to the value of the new
> parameter
I don't understand what's the difference between html and xhtml in this
respect. Can you elaborate further? The output from the XSL-T
transformation should be well-formed XML in any case, it cannot be
traditional HTML.
> would these pathces be accepted? (If not, then I don't want to bother,
> as it is then easier for me to do a copy-paste-edit cycle)
Please do provide them.
Ugo
P.S.: I haven't forgot about your calendar patches, they are on my TODO
list :-)
Re: CForms stylesheets - use of xsl:param and xhtml
Posted by Colin Paul Adams <co...@colina.demon.co.uk>.
>>>>> "Joerg" == Joerg Heinicke <jo...@gmx.de> writes:
Joerg> I prefer the postprocessing much more. If we put the
Joerg> elements into XHTML by default and postprocess them to HTML
Joerg> or the other way around - who cares. But please not doing
Joerg> this parameterized using xsl:element.
Well, it certainly suits me too.
--
Colin Paul Adams
Preston Lancashire
Re: CForms stylesheets - use of xsl:param and xhtml
Posted by Joerg Heinicke <jo...@gmx.de>.
On 29.06.2004 18:55, Bruno Dumon wrote:
> On Tue, 2004-06-29 at 18:17, Colin Paul Adams wrote:
>
>>>>>>>"Bruno" == Bruno Dumon <br...@outerthought.org> writes:
>>
>> Bruno> How will you do this, generate all elements with
>> Bruno> xsl:element?
>>
>>Yes.
>>At least, only those whose parent is not an html/xhtml element.
>
>
> So the namespace of an element made using xsl:element is inherited by
> literally-defined elements?
No, how shall this work?
>> Bruno> I wonder if that won't slow it down too
>> Bruno> much... (besides reducing readability).
>>
>>It isn't much less readable, and I doubt if anyone will notice the
>>performance difference - I think it will be very small.
>
>
> Let's hope so :-)
I don't fear performance, but readability is reduced massively IMO.
>> Bruno> Alternatively, wouldn't it be possible to transform the
>> Bruno> html XSLs using XSL to an XHTML equivalent?
>>
>>Probably. You are suggesting that this should be done as a cocoon
>>build-time task?
>
>
> I'm not suggesting anything, it could be a possibility. But I'm also
> fine with your approach, as long as my concerns aren't true.
I prefer the postprocessing much more. If we put the elements into XHTML
by default and postprocess them to HTML or the other way around - who
cares. But please not doing this parameterized using xsl:element.
Joerg
Re: CForms stylesheets - use of xsl:param and xhtml
Posted by Colin Paul Adams <co...@colina.demon.co.uk>.
>>>>> "Bruno" == Bruno Dumon <br...@outerthought.org> writes:
Bruno> BTW, what's the advantage of using XHTML? What browser does
Bruno> support it?
To answer you second question first: Epiphany, apparently (and
therefore presumably all Gecko-based browsers).
The reason why I believe this to be the case, is having made my
changes, and then serialzed using the xhtml11 serializser - on a
documented created from an html (NOT xhtml) source (i.e. form sample
1), I get serialized a document which purports to be (i.e. it's DTD
says it is) XHTML 1.1, but is actually a mixture (the stylesheet rules
just copy through the html body and head elements using the default
template, whereas they are adding xhtml namespace for their
descendants).
This apparently explains why epiphany is NOT display "Sample form" in
the browser's title bar - as Opera 7.51 is doing; but displays it on
the page itself - as plain text.
My explanation - Epiphany (but NOT Opera 7.51 - shame on it!) has
noticed the strict DTD, noticed that <head> is not in that DTD
(<head xmlns="http://www.w3.org/1999/xhtml"> is), and so has not
interpreted it's <title> child as a hint that it's text value should
be displayed in the title bar of the browser.
And to answer now your first question - you know where you are with
XHTML 1.1 (or 1.0 Strict) - the rules are clear, and if the browser
doesn't obey them, that's not your fault.
And the chances are, the next release of the faulty browser WILL obey
them. I think the tendency is clear.
That's my take on the subject, anyway.
--
Colin Paul Adams
Preston Lancashire
Re: CForms stylesheets - use of xsl:param and xhtml
Posted by Colin Paul Adams <co...@colina.demon.co.uk>.
>>>>> "Bruno" == Bruno Dumon <br...@outerthought.org> writes:
>> what you have just pointed out (above), and sighed. But I then
>> positively groaned as i realised the contents of the span was a
>> table - illegal - span can only contain inline elements - html
>> 4.01 or any xhtml (I don't bother to check earlier DTDs).
>>
>> So what do I do?
Bruno> fix it ;-)
Doing it - and going to see if anything breaks.
Bruno> It might help if you mention where this is done
Bruno> (stylesheet/template).
forms-advanced-field-styling.xsl
<xsl:template match="fi:multivaluefield[fi:styling/@list-type='double-listbox']">
(maybe elsewhere too, I don't know).
--
Colin Paul Adams
Preston Lancashire
Re: CForms stylesheets - use of xsl:param and xhtml
Posted by Bruno Dumon <br...@outerthought.org>.
On Tue, 2004-06-29 at 19:10, Colin Paul Adams wrote:
> >>>>> "Bruno" == Bruno Dumon <br...@outerthought.org> writes:
>
> >> Yes. At least, only those whose parent is not an html/xhtml
> >> element.
>
> Bruno> So the namespace of an element made using xsl:element is
> Bruno> inherited by literally-defined elements?
>
> Afraid not - as I realised two minutes ago :-)
>
> Bruno> Let's hope so :-)
>
> Well, on what I've coded so far - definitely not (when I hit the
> reload button - I have to look twice - generation is zero time to my perceptions).
yeah, you'd have to be fast to see the difference between 50 en 75
milliseconds, but it sure would be noticeable if you have dozens of
concurrent requests to handle. But I'm still not implying there is such
degration in performance -- in fact, likely not.
>
> However, the existing stylesheets are not valid anything, so it is
> defeating my purpose (of generating valid xhtml) from proceeding as I
> have been - at least without further changes.
BTW, what's the advantage of using XHTML? What browser does support it?
>
> I had just got as far as changing a span into an xsl:element - and
> then looked at it's child.
> It was at that point I realised what you have just pointed out
> (above), and sighed.
> But I then positively groaned as i realised the contents of the span
> was a table - illegal - span can only contain inline elements - html
> 4.01 or any xhtml (I don't bother to check earlier DTDs).
>
> So what do I do?
fix it ;-)
>
> The span concerned is just apparently surrounding the table with core
> attributes - which can equally go on the table itself - so the obvious
> solution is to just transfer these attributes to the table element. No
> difference as far as (x)html is concerned.
> But maybe there is a knock-on effect somewhere? Perhaps there is java
> code somewhere that expects this structure? I don't know. Can someone
> advise me please?
It might help if you mention where this is done (stylesheet/template).
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
Re: CForms stylesheets - use of xsl:param and xhtml
Posted by Colin Paul Adams <co...@colina.demon.co.uk>.
>>>>> "Bruno" == Bruno Dumon <br...@outerthought.org> writes:
>> Yes. At least, only those whose parent is not an html/xhtml
>> element.
Bruno> So the namespace of an element made using xsl:element is
Bruno> inherited by literally-defined elements?
Afraid not - as I realised two minutes ago :-)
Bruno> Let's hope so :-)
Well, on what I've coded so far - definitely not (when I hit the
reload button - I have to look twice - generation is zero time to my perceptions).
However, the existing stylesheets are not valid anything, so it is
defeating my purpose (of generating valid xhtml) from proceeding as I
have been - at least without further changes.
I had just got as far as changing a span into an xsl:element - and
then looked at it's child.
It was at that point I realised what you have just pointed out
(above), and sighed.
But I then positively groaned as i realised the contents of the span
was a table - illegal - span can only contain inline elements - html
4.01 or any xhtml (I don't bother to check earlier DTDs).
So what do I do?
The span concerned is just apparently surrounding the table with core
attributes - which can equally go on the table itself - so the obvious
solution is to just transfer these attributes to the table element. No
difference as far as (x)html is concerned.
But maybe there is a knock-on effect somewhere? Perhaps there is java
code somewhere that expects this structure? I don't know. Can someone
advise me please?
--
Colin Paul Adams
Preston Lancashire
Re: CForms stylesheets - use of xsl:param and xhtml
Posted by Bruno Dumon <br...@outerthought.org>.
On Tue, 2004-06-29 at 18:17, Colin Paul Adams wrote:
> >>>>> "Bruno" == Bruno Dumon <br...@outerthought.org> writes:
>
> Bruno> How will you do this, generate all elements with
> Bruno> xsl:element?
>
> Yes.
> At least, only those whose parent is not an html/xhtml element.
So the namespace of an element made using xsl:element is inherited by
literally-defined elements?
>
> Bruno> I wonder if that won't slow it down too
> Bruno> much... (besides reducing readability).
>
> It isn't much less readable, and I doubt if anyone will notice the
> performance difference - I think it will be very small.
Let's hope so :-)
>
> Bruno> Alternatively, wouldn't it be possible to transform the
> Bruno> html XSLs using XSL to an XHTML equivalent?
>
> Probably. You are suggesting that this should be done as a cocoon
> build-time task?
I'm not suggesting anything, it could be a possibility. But I'm also
fine with your approach, as long as my concerns aren't true.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
Re: CForms stylesheets - use of xsl:param and xhtml
Posted by Colin Paul Adams <co...@colina.demon.co.uk>.
>>>>> "Bruno" == Bruno Dumon <br...@outerthought.org> writes:
Bruno> How will you do this, generate all elements with
Bruno> xsl:element?
Yes.
At least, only those whose parent is not an html/xhtml element.
Bruno> I wonder if that won't slow it down too
Bruno> much... (besides reducing readability).
It isn't much less readable, and I doubt if anyone will notice the
performance difference - I think it will be very small.
Bruno> Alternatively, wouldn't it be possible to transform the
Bruno> html XSLs using XSL to an XHTML equivalent?
Probably. You are suggesting that this should be done as a cocoon
build-time task?
--
Colin Paul Adams
Preston Lancashire
Re: CForms stylesheets - use of xsl:param and xhtml
Posted by Bruno Dumon <br...@outerthought.org>.
On Tue, 2004-06-29 at 17:39, Colin Paul Adams wrote:
> The stylesheets in $COCOON_ROOT/src/blocks/samples/resources only
> handle html input/output.
> I use xhtml exclusively. Whilst I can easily copy the stylesheets to a
> private directory, and change them to work with xhtml instead, I would
> then have to re-work them every time changes were made to the
> distrbuted versions. Also other people would not benefit.
>
> So I thought it would be pretty easy to
> change the stylesheets so they could cope with either html or xhtml
> input (generating output as html for html input and xhtml as xhtml
> output).
How will you do this, generate all elements with xsl:element? I wonder
if that won't slow it down too much... (besides reducing readability).
Alternatively, wouldn't it be possible to transform the html XSLs using
XSL to an XHTML equivalent?
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org