You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Nicola Ken Barozzi <ni...@apache.org> on 2004/06/04 12:45:40 UTC
SVG from skinconf issues
I'm not able to see the project and group logos of the test site
generated using Batik. Commenting out the DTD from the skinconf.xml file
fixes it.
Any idea about how to fix it?
Wait, there's more that IMHO is relevant to this.
We have now two methods of injecting skinconf values in svg files:
- the "old" one that uses a for: namespace to identify special tags that
get substituted from the skinconf
- the "newer" one that uses xslt.svg files to create svgs from
skinconf.xml using that file as an xslt
I don't like the old one as it "pollutes" the svg with extra namespaces.
In essence, this is what happens: the file is passed through this
strylesheet:
<xsl:param name="config-file" />
<xsl:variable name="config"
select="document($config-file)/skinconfig"/>
<xsl:template match="for:project-name">
<xsl:value-of select="$config/project-name"/>
</xsl:template>
<xsl:template match="for:group-name">
<xsl:value-of select="$config/group-name"/>
</xsl:template>
which of course does not deal with all skinconf values, and does not
give us colors.
We could simply use the xslt.svg system and deprecate the <for:> usage,
but I'm not sure.
Here is how it is now and after how it can be with xslt.svg:
<svg xmlns="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:for="http://xml.apache.org/forrest" width="220" height="65" >
<title>Anteater logo</title>
<defs>...</defs>
<g filter="url(#shadowFilter)" fill="url(#gradient)">
<text x="40%" y="60%" style="blahblah">
<for:group-name />
</text>
</g>
</svg>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="skinconfig">
<svg xmlns="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink">
<title>Anteater logo</title>
<defs>...</defs>
<g filter="url(#shadowFilter)" fill="url(#gradient)">
<text x="40%" y="60%" style="blahblah">
<xsl:value-of select="group-name"/>
</text>
</g>
</svg>
</xsl:template>
</xsl:stylesheet>
What changes is the fact that now the file is enclosed in two other tags
and the use of value-of instead of <for:>, and the for namespace is no more.
An alternative is to do this:
<svg xmlns="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:skinconf="http://xml.apache.org/forrest/sf">
<title>Anteater logo</title>
<defs>...</defs>
<g filter="url(#shadowFilter)" fill="url(#gradient)">
<text x="40%" y="60%" style="blahblah">
<skinconf:value-of select="group-name"/>
</text>
</g>
</svg>
Where a stylesheet encloses this file in the xsl stylesheet tags and
transforms that skinconf: tags in xslt values.
But this basically creates our templating language... we've been through
this already, and at that time we said to try the xslt.svg way.
Now, WDOT?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: SVG from skinconf issues
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Juan Jose Pablos wrote:
> Nicola Ken Barozzi escribió:
>
>> Well, even if SVN does not follow moves automatically you can do it
>> manually. Get the old version using the version number and diff it
>> locally.
>
> like this?
>
> cheche@yarel:~/xml/forrest/trunk$ svn update -r20591 status.xml
> D status.xml
> Updated to revision 20591.
>
> If I try to get an old version, it will be removed.
Because you should try to get it from xml/forrest/trunk/status.xml,
where it was at that time.
>>> But move this from "for" to skinconf is trivial.
>>
>> ?
>
> moving from for: namespace to skinconf: namespace is trivial.
But that was not the point :-)
>> Hmmm... you are right. The xslt is ok of used in a skin as it is now,
>> but it mixes concerns if used in content.
>>
>> Then what about keeping the old for: namespace and adding a new
>> skinconf-value-of tag that selects directly from the skinconf?
>>
>
> I would not worry too much about the namespace.
>
>> <for:skinconf-value-of select="group-name"/>
>
> well, looking at your mail the only issue with this setup is that it is
> not generalize to all the elements in the skinconf. So maybe we need to
> have a better way of handle elementes on
> ./context/resources/stylesheets/project2text.xsl
>
> WDYT?
That's what I was saying now :-)
In fact <for:skinconf-value-of select="group-name"/> is a generalization
of the current for: system.
In any case we agree, I'll do this then.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: SVG from skinconf issues
Posted by Juan Jose Pablos <ch...@che-che.com>.
David Crossley escribió:
>
> Cheche, did you not see Fitz' reply to your bug report
> to infrastructure@a.o this morning ...
>
Yes David, I saw that, but I thought that nicola had a work around that
problem
Re: SVG from skinconf issues
Posted by David Crossley <cr...@apache.org>.
Juan Jose Pablos wrote:
> Nicola Ken Barozzi escribió:
> >
> > Well, even if SVN does not follow moves automatically you can do it
> > manually. Get the old version using the version number and diff it locally.
>
> like this?
>
> cheche@yarel:~/xml/forrest/trunk$ svn update -r20591 status.xml
> D status.xml
> Updated to revision 20591.
>
> If I try to get an old version, it will be removed.
Cheche, did you not see Fitz' reply to your bug report
to infrastructure@a.o this morning ...
Here is the snippet ...
------
Brian W. Fitzpatrick wrote:
> David Crossley wrote:
>> I see now that you mean that diffs cannot be done against
>> revisions from before the repository move.
>
> It's a known bug. You need to tell svn the old path to
> diff against because diff currently doesn't "follow copies".
>
> This bug will be fixed in 1.1, which will be coming out
> later this year (date is still TBD).
------
Re: SVG from skinconf issues
Posted by Juan Jose Pablos <ch...@che-che.com>.
Nicola Ken Barozzi escribió:
>
> Well, even if SVN does not follow moves automatically you can do it
> manually. Get the old version using the version number and diff it locally.
like this?
cheche@yarel:~/xml/forrest/trunk$ svn update -r20591 status.xml
D status.xml
Updated to revision 20591.
If I try to get an old version, it will be removed.
>> But move this from "for" to skinconf is trivial.
>
>
> ?
>
moving from for: namespace to skinconf: namespace is trivial.
>
> Hmmm... you are right. The xslt is ok of used in a skin as it is now,
> but it mixes concerns if used in content.
>
> Then what about keeping the old for: namespace and adding a new
> skinconf-value-of tag that selects directly from the skinconf?
>
I would not worry too much about the namespace.
> <for:skinconf-value-of select="group-name"/>
well, looking at your mail the only issue with this setup is that it is
not generalize to all the elements in the skinconf. So maybe we need to
have a better way of handle elementes on
./context/resources/stylesheets/project2text.xsl
WDYT?
Cheers,
Cheche
Re: SVG from skinconf issues
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Juan Jose Pablos wrote:
> Nicola Ken Barozzi escribió:
>
>>
>> I'm not able to see the project and group logos of the test site
>> generated using Batik. Commenting out the DTD from the skinconf.xml
>> file fixes it.
>>
>> Any idea about how to fix it?
>
> It is all related to the fact that a context is not created anymore,
> since there is a problem to access to previous version to the SVN, I am
> kind of stuck with this problem.
Well, even if SVN does not follow moves automatically you can do it
manually. Get the old version using the version number and diff it locally.
>> I don't like the old one as it "pollutes" the svg with extra namespaces.
>> In essence, this is what happens: the file is passed through this
>> strylesheet:
>>
> But move this from "for" to skinconf is trivial.
?
>>
>> We could simply use the xslt.svg system and deprecate the <for:>
>> usage, but I'm not sure.
>>
>
> I think that we have to issues here:
>
> One is the use of for: and skinconf: namespaces.
>
> +1 as this is not important, it could be foo if we wish..
xslt.svg does not use skinconf: namespace, it's all xslt.
>> What changes is the fact that now the file is enclosed in two other
>> tags and the use of value-of instead of <for:>, and the for namespace
>> is no more
>
> I think that this mix things, in the old way you have the content in one
> file. The for: namespace would be ignore unless you use it within
> forrest. Now you are mixing this data with code (XLST).
Hmmm... you are right. The xslt is ok of used in a skin as it is now,
but it mixes concerns if used in content.
Then what about keeping the old for: namespace and adding a new
skinconf-value-of tag that selects directly from the skinconf?
<svg xmlns="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:for="http://xml.apache.org/forrest/">
<title>Anteater logo</title>
<defs>...</defs>
<g filter="url(#shadowFilter)" fill="url(#gradient)">
<text x="40%" y="60%" style="blahblah">
<for:skinconf-value-of select="group-name"/>
</text>
</g>
</svg>
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: SVG from skinconf issues
Posted by Juan Jose Pablos <ch...@che-che.com>.
Nicola Ken Barozzi escribió:
>
> I'm not able to see the project and group logos of the test site
> generated using Batik. Commenting out the DTD from the skinconf.xml file
> fixes it.
>
> Any idea about how to fix it?
>
It is all related to the fact that a context is not created anymore,
since there is a problem to access to previous version to the SVN, I am
kind of stuck with this problem.
> I don't like the old one as it "pollutes" the svg with extra namespaces.
> In essence, this is what happens: the file is passed through this
> strylesheet:
>
But move this from "for" to skinconf is trivial.
>
> We could simply use the xslt.svg system and deprecate the <for:> usage,
> but I'm not sure.
>
I think that we have to issues here:
One is the use of for: and skinconf: namespaces.
+1 as this is not important, it could be foo if we wish..
>
> What changes is the fact that now the file is enclosed in two other tags
> and the use of value-of instead of <for:>, and the for namespace is no
> more
>
I think that this mix things, in the old way you have the content in one
file. The for: namespace would be ignore unless you use it within
forrest. Now you are mixing this data with code (XLST).
Re: SVG from skinconf issues
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Nicola Ken Barozzi wrote:
...
> In any case, I am starting to believe that the for: system should be
> used also in the skins instead of the xslt used now where possible.
>
> Also, this could fix the problem we have with css files not being
> traversed.
>
> <for:text>
> css file stuff..
> ... <for:text src="put the link here"/>
> ... <for:skinconf select="group"/>
>
> </for:text>
>
> Would give:
>
> css file stuff..
> ... put the link here
> ... group-value
>
> It would not make all css files be automagically traversed, but if one
> uses this system it cam make them be traversed.
GOsh, I have to take this back... the system now used cannot be easily
changed with another one, as it uses more xslt elements that I thought.
For the images in svg it does calculations and logic, while in the css
it uses xslt import.
For now, I'll simply fix the current for: usage and the css links
without changing the whole system that works well nevertheless. If
someone else wants to try though and find a better way, he's always
welcome :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: SVG from skinconf issues
Posted by Rick Tessner <ri...@onnadayr.ca>.
On Mon, 2004-06-07 at 13:35, Nicola Ken Barozzi wrote:
> You are asking: "is skinconf content or presentation"?
> Answer: it's metadata. Mostly, if not all, *presentation* metadata.
>
> If I remove the page contents, it will not work. If I remove the logo,
> it will still work. Hence, the logo is presentation.
I like this. Clear cut method and definition of what is presentation
and what is content. Good.
> > 2. Move towards using an aggregated skinconf everywhere. This does
> > have a feel of mixing concerns to me. But that's only because
> > I'm not clear in what camp the skinconf actually lies. Is it
> > content? Is it content for the presentation layer? Is it both?
>
> Skinconf is presentation. But remember that once the content enters
> Cocoon, it does not need to remain separate from presentation. In fact
> the aggregation is a blob that contains both data, metadata, style info,
> etc. At that point in processing, it's not theoretically a problem.
This makes sense. I like. :)
> I'm now going to focus on trying to access skinconf in a consistent
> manner in the skin files.
I'm looking forward to it! Thanks.
--
Rick Tessner <ri...@onnadayr.ca>
Re: SVG from skinconf issues
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Not to get tedious, I'll snip lots of stuff. But I've read it all with
great intrest, and it has indeed given me more insight :-)
Rick Tessner wrote:
> On Sat, 2004-06-05 at 03:26, Nicola Ken Barozzi wrote:
...
>>If so, then why was the precedent proposal o transforming the content
>>with added <fo> namespace not ok? Because in that case we get only part
>>of the skinconf content, not all of it.
>
> I'll have to go search the archives to see what that proposal was ...
It's about making <fo:skinconf-value select=""/> tags work before the
xslt. As you see, they are resolved before the xslt, thus giving the
xslt a single tag, thus not making it possible for the xslt to perform
xpath queries (like asking how many trail items are present).
...
> If we do go this way, we'd need to use aggregate whenever we transform
> SVGs, the creation of PDFs (currently still require document()'ing
> skinconf), etc.
Correct. Every content source should contain it.
...
>>Also, this could fix the problem we have with css files not being traversed.
...
> <snip what="example of the issue and use of Batik CSS parser"/>
Forget it :-)
I'm fixing it in another way, gonna commit tomorrow probably.
> Recap:
>
> <quote who="Nicola">
> We need to be able to add skinconf to content. Sometimes we need all of
> it, sometimes we need just part of it. In the first case we aggregate,
> in the second case we inject values with <for:>.
> </quote>
I've changed my mind, all because of your comments :-)
You are asking: "is skinconf content or presentation"?
Answer: it's metadata. Mostly, if not all, *presentation* metadata.
If I remove the page contents, it will not work. If I remove the logo,
it will still work. Hence, the logo is presentation.
Let me be clear: content is not the only thing that conveys information,
as "how" something is said also affects the "what". Our task is to make
sure that core of the information given is in the content, all that is
*crucial* to be conveyed. We must keep presentation separate.
Now, let's get strict. If skinconf is presentation, it should *not* be
accessible from content.
Let's see a real world example where we need to access skinconf from
'content'... the logo. Wait, the logo is not content... so it should not
be in the content dir, but in the presentation dir.
documentation
/content - content
/skins <-- logo goes here - presentation
/resources - transformations
> Couple of options (my own choice would be #3 below).
>
> 1. Quick and dirty for a 0.6 release. We keep as is and remove the
> DOCTYPE declaration from skinconf so that where skinconf is
> document()'d, it'll work. This will impact validating editors
> and we'd need to make that clear.
Let's see if we can fix this quick, else we'll just do this to release.
> 2. Move towards using an aggregated skinconf everywhere. This does
> have a feel of mixing concerns to me. But that's only because
> I'm not clear in what camp the skinconf actually lies. Is it
> content? Is it content for the presentation layer? Is it both?
Skinconf is presentation. But remember that once the content enters
Cocoon, it does not need to remain separate from presentation. In fact
the aggregation is a blob that contains both data, metadata, style info,
etc. At that point in processing, it's not theoretically a problem.
> 3. Move towards an <xi:include> style of use. I personally do like
> this one.
3) as described by me puts it in the content, so it's not an option.
> As an end-user of Forrest, there are a couple of things I'd like to be
> able to do and I guess that what has determined my choice for the above.
>
> * I'd like to be able to edit the skinconf and have it validated.
'k
> * skinconf for content. There are times when I'd like to be able
> to get at the skinconf values and know that there is a
> guaranteed and consistent way of doing this (colour a background
> image generated out of SVG using skinconf colours, for example).
We have seen how the logo is presentation. Other example of needs?
> * skinconf for transformation. There are also times when I want
> to get skinconf values for my transformation sheets. Generating
> CSS using colours defined in the skinconf springs to mind.
This is already implemented, albeit in a strange way. See the *.css.xslt
files in the krysalis-site skin to see what I mean.
I'm now going to focus on trying to access skinconf in a consistent
manner in the skin files.
> Perhaps this would be the best way to approach this. How do people see
> the skinconf being used in real life and what would be the best approach
> to accomodate that?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: SVG from skinconf issues
Posted by Rick Tessner <ri...@onnadayr.ca>.
On Sat, 2004-06-05 at 03:26, Nicola Ken Barozzi wrote:
> Rick Tessner wrote:
> > We should just be able to use something like:
> >
> > <map:transform src="cocoon:/skinconf-document2fo.xsl"/>
> >
> > or in effect, run the XSL through a "skinconf" transformer (or somehow
> > generate an XSL from the skinconf.xml which could then be used against
> > SVG, XML docs and XSL)
> >
> > The "skinconf-*.xsl" could be resources that either:
> >
> > 1. Run the requested XSL through some sort of skinconf.xsl
> > generated from skinconf.xml or
> > 2. Run the requested XSL through a "SkinconfTransformer".
>
> This is an interesting proposal, but it seems to mix concerns to me.
> Skinconf is content, while xsls are tramsformations.
Hmmmm ... I don't think I'm really clear on this distinction in this
case. Skinconf is content for the skin (ie. information that can change
the look of the skin via the use of css and xslt).
Skinconf is part of the transformation. It is not part of the xdocs
(content).
Or have I missed something fundamental (always a possibility :)?
> If so, then why was the precedent proposal o transforming the content
> with added <fo> namespace not ok? Because in that case we get only part
> of the skinconf content, not all of it.
I'll have to go search the archives to see what that proposal was ...
> > Whatever is used could be used as an equi-pollutant manner for SVGs,
> > PDFs, or whatever other resources we may have that require skin
> > configuration.
>
> Since we aggregate, all output formats can and should use the aggregated
> skinconf.
The aggregated skinconf works, but it does get a bit cumbersome when we
need those values in various places.
If we do go this way, we'd need to use aggregate whenever we transform
SVGs, the creation of PDFs (currently still require document()'ing
skinconf), etc.
The PDF one I've looked at a couple of times and doesn't seem
straightforward (again, I may be missing something simple :).
> >>I guess that the best bet is to keep on using namespaced values for the
> >>documents and aggregation for the skins.
> >
> > It'd be nice to have one method for handling both, since fundamentally,
> > it is all just XML.
>
> Yeah, but we must clearly divide content from presentation.
I'm still struggling with this. I'm trying to figure out what skinconf
really is. Is it content? Or are they parameters used to configure the
skin? Logos I'd count as content. Menu placement and depth I'd count
as presentation.
> Trying to do another recap:
>
> We need to be able to add skinconf to content. Sometimes we need all of
> it, sometimes we need just part of it. In the first case we aggregate,
> in the second case we inject values with <for:>.
Yes. And sometimes, we need to add skinconf to the presentation
configuration layer. (Menu depth, page size/width for PDF)
> Wait a sec, is there any reason why we should not use xinclude instead?
>
> <xi:include href="skinconf.xml#xpointer(/skinconfig/group)"
> parse="xml"/>
>
> In fact there is an issue, that we should always use the internal
> skinconf, not the original one, so it would be:
>
> <xi:include href="cocoon://skinconf#xpointer(/skinconfig/group)"
> parse="xml"/>
I like the idea of this. No re-inventing the wheel with a skinconf
transformer.
> Also, it's much mor verbose than:
>
> <for:skinconf select="group"/>
Yes, same idea as the <xi:include> with a cleaner syntax.
> In any case, I am starting to believe that the for: system should be
> used also in the skins instead of the xslt used now where possible.
>
> Also, this could fix the problem we have with css files not being traversed.
Not clear on this issue. Time to go read the archives. :)
<snip what="example of the issue and use of Batik CSS parser"/>
Recap:
<quote who="Nicola">
We need to be able to add skinconf to content. Sometimes we need all of
it, sometimes we need just part of it. In the first case we aggregate,
in the second case we inject values with <for:>.
</quote>
I'd like to add to this that we also, in effect, add skinconf to the
transformations. This is currently done by aggregating the skinconf
with the content we wish to transform and then use this aggregated
skinconf from the XSL itself.
This does have the feel of mixing concerns. However, the skinconf is
used by both the content and by the transformations.
Couple of options (my own choice would be #3 below).
1. Quick and dirty for a 0.6 release. We keep as is and remove the
DOCTYPE declaration from skinconf so that where skinconf is
document()'d, it'll work. This will impact validating editors
and we'd need to make that clear.
2. Move towards using an aggregated skinconf everywhere. This does
have a feel of mixing concerns to me. But that's only because
I'm not clear in what camp the skinconf actually lies. Is it
content? Is it content for the presentation layer? Is it both?
3. Move towards an <xi:include> style of use. I personally do like
this one.
As an end-user of Forrest, there are a couple of things I'd like to be
able to do and I guess that what has determined my choice for the above.
* I'd like to be able to edit the skinconf and have it validated.
* skinconf for content. There are times when I'd like to be able
to get at the skinconf values and know that there is a
guaranteed and consistent way of doing this (colour a background
image generated out of SVG using skinconf colours, for example).
* skinconf for transformation. There are also times when I want
to get skinconf values for my transformation sheets. Generating
CSS using colours defined in the skinconf springs to mind.
Perhaps this would be the best way to approach this. How do people see
the skinconf being used in real life and what would be the best approach
to accomodate that?
--
Rick Tessner <ri...@onnadayr.ca>
Re: SVG from skinconf issues
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Rick Tessner wrote:
> On Fri, 2004-06-04 at 09:38, Nicola Ken Barozzi wrote:
>
...
>>Recap:
>>
>>1 - to get the skinconf values from the *skins* we aggregate
>>2 - to get the skinconf values from svg we have come to the conclusion
>>that the best way is to use an extra namespace and inject the values
>>
>>You are basically saying: why not simply use case 2 for all and even
>>make that into a special transformer?
>>
>>The problem is that these values are to be given the xsl, not the
>>document itself, so to make this equipollent we should make an xsl
>>extension, not an xml extension (namespaces).
>
> What about transforming the XSL before using it? Afterall, XSL is just
> XML and cocoon would cache the result of that transformation ... :)
True...
> We should just be able to use something like:
>
> <map:transform src="cocoon:/skinconf-document2fo.xsl"/>
>
> or in effect, run the XSL through a "skinconf" transformer (or somehow
> generate an XSL from the skinconf.xml which could then be used against
> SVG, XML docs and XSL)
>
> The "skinconf-*.xsl" could be resources that either:
>
> 1. Run the requested XSL through some sort of skinconf.xsl
> generated from skinconf.xml or
> 2. Run the requested XSL through a "SkinconfTransformer".
This is an interesting proposal, but it seems to mix concerns to me.
Skinconf is content, while xsls are tramsformations.
If so, then why was the precedent proposal o transforming the content
with added <fo> namespace not ok? Because in that case we get only part
of the skinconf content, not all of it.
> Whatever is used could be used as an equi-pollutant manner for SVGs,
> PDFs, or whatever other resources we may have that require skin
> configuration.
Since we aggregate, all output formats can and should use the aggregated
skinconf.
>>I guess that the best bet is to keep on using namespaced values for the
>>documents and aggregation for the skins.
>
> It'd be nice to have one method for handling both, since fundamentally,
> it is all just XML.
Yeah, but we must clearly divide content from presentation.
Trying to do another recap:
We need to be able to add skinconf to content. Sometimes we need all of
it, sometimes we need just part of it. In the first case we aggregate,
in the second case we inject values with <for:>.
Wait a sec, is there any reason why we should not use xinclude instead?
<xi:include href="skinconf.xml#xpointer(/skinconfig/group)"
parse="xml"/>
In fact there is an issue, that we should always use the internal
skinconf, not the original one, so it would be:
<xi:include href="cocoon://skinconf#xpointer(/skinconfig/group)"
parse="xml"/>
Also, it's much mor verbose than:
<for:skinconf select="group"/>
In any case, I am starting to believe that the for: system should be
used also in the skins instead of the xslt used now where possible.
Also, this could fix the problem we have with css files not being traversed.
<for:text>
css file stuff..
... <for:text src="put the link here"/>
... <for:skinconf select="group"/>
</for:text>
Would give:
css file stuff..
... put the link here
... group-value
It would not make all css files be automagically traversed, but if one
uses this system it cam make them be traversed.
BTW, Batik has a CSS parser, if anyone wants to make an xml version of
CSS...
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: SVG from skinconf issues
Posted by Rick Tessner <ri...@onnadayr.ca>.
On Fri, 2004-06-04 at 09:38, Nicola Ken Barozzi wrote:
> > Will look over your ideas below. My initial thought was creating
> > something for the skinconf similiar to how "site:" and "ext:" links are
> > handled via the LinkRewriter but not sure how feasible that would be or
> > what the impact on processing would be. This transformer could work on
> > elements in a "skinconf:" (polluting :) namespace. This would allow the
> > skinconf.xml to be more free-form as well, similiar to site.xml.
>
> Why can't it be freeform now? We use xpath in the aggregated doc.
True ...
> Recap:
>
> 1 - to get the skinconf values from the *skins* we aggregate
> 2 - to get the skinconf values from svg we have come to the conclusion
> that the best way is to use an extra namespace and inject the values
>
> You are basically saying: why not simply use case 2 for all and even
> make that into a special transformer?
>
> The problem is that these values are to be given the xsl, not the
> document itself, so to make this equipollent we should make an xsl
> extension, not an xml extension (namespaces).
What about transforming the XSL before using it? Afterall, XSL is just
XML and cocoon would cache the result of that transformation ... :)
We should just be able to use something like:
<map:transform src="cocoon:/skinconf-document2fo.xsl"/>
or in effect, run the XSL through a "skinconf" transformer (or somehow
generate an XSL from the skinconf.xml which could then be used against
SVG, XML docs and XSL)
The "skinconf-*.xsl" could be resources that either:
1. Run the requested XSL through some sort of skinconf.xsl
generated from skinconf.xml or
2. Run the requested XSL through a "SkinconfTransformer".
Whatever is used could be used as an equi-pollutant manner for SVGs,
PDFs, or whatever other resources we may have that require skin
configuration.
Thoughts?
> I guess that the best bet is to keep on using namespaced values for the
> documents and aggregation for the skins.
It'd be nice to have one method for handling both, since fundamentally,
it is all just XML.
--
Rick Tessner <ri...@onnadayr.ca>
Re: SVG from skinconf issues
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Rick Tessner wrote:
> On Fri, 2004-06-04 at 03:45, Nicola Ken Barozzi wrote:
>
>>I'm not able to see the project and group logos of the test site
>>generated using Batik. Commenting out the DTD from the skinconf.xml file
>>fixes it.
...
> So, anywhere that the skinconf.xml is document()'d, there should be some
> odd behaviour.
>
> That includes the following:
>
> ./src/core/context/skins/common/xslt/fo/document2fo.xsl
> ./src/core/context/skins/common/xslt/fo/footerinfo.xsl
> ./src/core/context/skins/common/xslt/svg/document2svg.xsl
> ./src/core/context/resources/stylesheets/changes2rss.xsl
> ./src/core/context/resources/stylesheets/project2text.xsl
Ugh :-/
>>Any idea about how to fix it?
>
> Will look over your ideas below. My initial thought was creating
> something for the skinconf similiar to how "site:" and "ext:" links are
> handled via the LinkRewriter but not sure how feasible that would be or
> what the impact on processing would be. This transformer could work on
> elements in a "skinconf:" (polluting :) namespace. This would allow the
> skinconf.xml to be more free-form as well, similiar to site.xml.
Why can't it be freeform now? We use xpath in the aggregated doc.
> It'd be nice to be able to just run various bits through a transformer
> rather than creating aggregates that include "skinconf.xml" each time
> ...
Hmmm... nice thoughts...
Recap:
1 - to get the skinconf values from the *skins* we aggregate
2 - to get the skinconf values from svg we have come to the conclusion
that the best way is to use an extra namespace and inject the values
You are basically saying: why not simply use case 2 for all and even
make that into a special transformer?
The problem is that these values are to be given the xsl, not the
document itself, so to make this equipollent we should make an xsl
extension, not an xml extension (namespaces).
I guess that the best bet is to keep on using namespaced values for the
documents and aggregation for the skins.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: SVG from skinconf issues
Posted by David Crossley <cr...@apache.org>.
Antonio Gallardo wrote:
> David Crossley dijo:
> > Yes, here one possible Xalan bug. They asked recently if
> > someone could provide a testcase.
> > http://issues.apache.org/bugzilla/show_bug.cgi?id=28341
> > EntityResolver not passed to subsequent parsers
>
> The bug is for 2.5 perhaps we can confirm the same for 2.6, WDYT?
I added testcases and raised it to xalan-2.6
--David
Re: SVG from skinconf issues
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
David Crossley dijo:
> Yes, here one possible Xalan bug. They asked recently if
> someone could provide a testcase.
> http://issues.apache.org/bugzilla/show_bug.cgi?id=28341
> EntityResolver not passed to subsequent parsers
The bug is for 2.5 perhaps we can confirm the same for 2.6, WDYT?
Best Regards,
Antonio Gallardo
Re: SVG from skinconf issues
Posted by David Crossley <cr...@apache.org>.
Rick Tessner wrote:
> Nicola Ken Barozzi wrote:
> > I'm not able to see the project and group logos of the test site
> > generated using Batik. Commenting out the DTD from the skinconf.xml file
> > fixes it.
>
> Yup, been seeing that recently myself as well.
>
> An unfortunate side-effect of removing the DOCTYPE declaration from the
> skinconf.xml is that the "validate-skinconf" target fails ... (Currently
> happens with a run of "forrest war" target).
>
> The reason that removing the DOCTYPE declaration works in allowing the
> images to be generated is that the "project2text.xsl" uses document() on
> the the skinconf.xml and the entity resolver doesn't currently work on
> document()'d documents (Xalan issue, I suppose).
Yes, here one possible Xalan bug. They asked recently if
someone could provide a testcase.
http://issues.apache.org/bugzilla/show_bug.cgi?id=28341
EntityResolver not passed to subsequent parsers
--David
> Actually, I should say that resolution of the PUBLIC identifier fails
> (since it can't find the various DTD catalogs). It will try the SYSTEM
> identifier and if it finds that, it will succeed.
>
> So, anywhere that the skinconf.xml is document()'d, there should be some
> odd behaviour.
>
> That includes the following:
>
> ./src/core/context/skins/common/xslt/fo/document2fo.xsl
> ./src/core/context/skins/common/xslt/fo/footerinfo.xsl
> ./src/core/context/skins/common/xslt/svg/document2svg.xsl
> ./src/core/context/resources/stylesheets/changes2rss.xsl
> ./src/core/context/resources/stylesheets/project2text.xsl
>
> > Any idea about how to fix it?
>
> Will look over your ideas below. My initial thought was creating
> something for the skinconf similiar to how "site:" and "ext:" links are
> handled via the LinkRewriter but not sure how feasible that would be or
> what the impact on processing would be. This transformer could work on
> elements in a "skinconf:" (polluting :) namespace. This would allow the
> skinconf.xml to be more free-form as well, similiar to site.xml.
>
> It'd be nice to be able to just run various bits through a transformer
> rather than creating aggregates that include "skinconf.xml" each time
> ...
>
> I suspect your ideas below are a little more feasible. More later once
> I have a chance to look them over and think about it a bit.
>
> <snip what="various ideas on how to handle this issue"/>
Re: SVG from skinconf issues
Posted by Rick Tessner <ri...@onnadayr.ca>.
On Fri, 2004-06-04 at 03:45, Nicola Ken Barozzi wrote:
> I'm not able to see the project and group logos of the test site
> generated using Batik. Commenting out the DTD from the skinconf.xml file
> fixes it.
Yup, been seeing that recently myself as well.
An unfortunate side-effect of removing the DOCTYPE declaration from the
skinconf.xml is that the "validate-skinconf" target fails ... (Currently
happens with a run of "forrest war" target).
The reason that removing the DOCTYPE declaration works in allowing the
images to be generated is that the "project2text.xsl" uses document() on
the the skinconf.xml and the entity resolver doesn't currently work on
document()'d documents (Xalan issue, I suppose).
Actually, I should say that resolution of the PUBLIC identifier fails
(since it can't find the various DTD catalogs). It will try the SYSTEM
identifier and if it finds that, it will succeed.
So, anywhere that the skinconf.xml is document()'d, there should be some
odd behaviour.
That includes the following:
./src/core/context/skins/common/xslt/fo/document2fo.xsl
./src/core/context/skins/common/xslt/fo/footerinfo.xsl
./src/core/context/skins/common/xslt/svg/document2svg.xsl
./src/core/context/resources/stylesheets/changes2rss.xsl
./src/core/context/resources/stylesheets/project2text.xsl
> Any idea about how to fix it?
Will look over your ideas below. My initial thought was creating
something for the skinconf similiar to how "site:" and "ext:" links are
handled via the LinkRewriter but not sure how feasible that would be or
what the impact on processing would be. This transformer could work on
elements in a "skinconf:" (polluting :) namespace. This would allow the
skinconf.xml to be more free-form as well, similiar to site.xml.
It'd be nice to be able to just run various bits through a transformer
rather than creating aggregates that include "skinconf.xml" each time
...
I suspect your ideas below are a little more feasible. More later once
I have a chance to look them over and think about it a bit.
<snip what="various ideas on how to handle this issue"/>
--
Rick Tessner <ri...@onnadayr.ca>