[RT] XSL structure across projects -- was -->Re: HTML/CSS and graphics

[Robert Koberg <ro...@koberg.com>]

Hi all,

Bert Van Kets wrote:

>
> I volunteered for this job.  What are your ideas on this task?

------- General XSL Structure ---------

Will  xml.apache.org projects create their own look and feel? Will all 
xml.apache.org projects use the same XSL?
If used across all xml-projects, and if they create their own L&F, what 
can they change (just CSS? XSL?)?
If they can create their own XSLT, perhaps there should be 
xml-apache-rules (already in place?) about xsl:include vs. xsl:import 
and/or using a priority attribute on a template rule to override the 
base set of XSL.
-- xsl:include used for things that should never be changed (examples: 
copyright, nav)
-- xsl:import used for things that can be overriden
-- or, perhaps just have the project create a high priority on a 
template rule so they override the base set. This makes me think of 
another question:
Is there some facility in place (or planned) to check a project 
directory and see if they have XSL that should be used to override the 
base set?
-- (perhaps this has already been said??) I suggest including a 
'global_definitions.xsl' (or named whatever) from each of the project 
sites into a base set of XSL. A project has control over the file and 
can include/import/prioritize anyway they want - within the rules.
-- there would also be a global_defintions.xsl for each of the projects 
in the base set of XSL. These import/include all of the common XSL. make 
sense?

what do you think?

-Rob

Re: [RT] XSL structure across projects -- was -->Re: HTML/CSS and graphics

[Bert Van Kets <be...@vankets.com>]

At 02:51 24/05/2002 -0700, you wrote:
>Hi folks,
>
>Steven Noels wrote:
>
>>On Thu, 23 May 2002, Robert Koberg wrote:
>>
>>
>>
>>>>If they can create their own XSLT, perhaps there should be 
>>>>xml-apache-rules (already in place?) about xsl:include vs. xsl:import 
>>>>and/or using a priority attribute on a template rule to override the 
>>>>base set of XSL.
>>>>
>>
>>We should be cautious on xsl:import/include since this conflicts with 
>>stylesheet caching... same with the document() function - to be avoided 
>>if possible. Think about this before choosing a direction.
>
>I have been looking for a way to use componetized XSLTs without 
>include/import. I see how Forrest uses book2menu which does an inital 
>transformation producing a new result which is then transformed again. Is 
>this considered the correct way to handle component XSLT?
>
>Someone on the user list suggested that I use a pipeline to aggregate the 
>XSLT, is there an example or thread you can point me to (I cannot find 
>info and can't find it in my hacking)?

IMHO The best way of putting things together in Cocoon (Forrest is a Cocoon 
implementation/application) is using pipelines.  The docs section of the 
Cocoon site is built up this way. Check out the sitemap in the 
Cocoon/documentation directory.
If you really need to merge XSLT's you need to have a look at 
<map:transform src="cocoon:/yourpipeline"/>  where "yourpipeline" points to 
a pipeline called "yourpipeline".  In that pipeline you aggregate the 
different XSLT's.  XSLT is after all a form of XML.

Bert

Re: [RT] XSL structure across projects -- was -->Re: HTML/CSS and graphics

[Robert Koberg <ro...@koberg.com>]

Yes, I quickly skimmed a great deal of pages looking for something that 
talked about using multiple XSLT on the same source file. I see how and 
understand what is happening in forrest. I just don't see the benefit of 
transforming into several intermediate stages.

I just wanted to give some XSLT to the group. I probably need to back 
down and learn more about cocoon before providing any more files. I was 
thinking I could get up and running faster...

Wondering out loud.... why do I need to know about the sitemap to patch 
XSLT? Where is the separation of concerns?

best,
-Rob


Steven Noels wrote:

>Rob,
>
>  
>
>>From: Robert Koberg [mailto:rob@koberg.com]
>>    
>>
>
><snip/>
>
>  
>
>>I must be missing something. What is the best (Forrest) way to bring
>>together component XSLT?
>>    
>>
>
>be sure you have read and understood
>http://xml.apache.org/cocoon/userdocs/concepts/index.html and
>http://xml.apache.org/cocoon/userdocs/concepts/sitemap.html (especially
>the section on Aggregation and Resources) prior to go in and try to
>patch Forrest. The Forrest Primer
>(http://xml.apache.org/forrest/primer.html) might help, also.
>
>Sitemap aggregation and XSLT import/include have nothing to do with each
>other.
>
></Steven>
>
>  
>

RE: [RT] XSL structure across projects -- was -->Re: HTML/CSS and graphics

[Steven Noels <st...@outerthought.org>]

Rob,

> From: Robert Koberg [mailto:rob@koberg.com]

<snip/>

> I must be missing something. What is the best (Forrest) way to bring
> together component XSLT?

be sure you have read and understood
http://xml.apache.org/cocoon/userdocs/concepts/index.html and
http://xml.apache.org/cocoon/userdocs/concepts/sitemap.html (especially
the section on Aggregation and Resources) prior to go in and try to
patch Forrest. The Forrest Primer
(http://xml.apache.org/forrest/primer.html) might help, also.

Sitemap aggregation and XSLT import/include have nothing to do with each
other.

</Steven>

Re: [RT] XSL structure across projects -- was -->Re: HTML/CSS and graphics

[Robert Koberg <ro...@koberg.com>]

Hi folks,

Steven Noels wrote:

>On Thu, 23 May 2002, Robert Koberg wrote:
>
>  
>
>>>If they can create their own XSLT, perhaps there should be 
>>>xml-apache-rules (already in place?) about xsl:include vs. xsl:import 
>>>and/or using a priority attribute on a template rule to override the 
>>>base set of XSL.
>>>      
>>>
>
>We should be cautious on xsl:import/include since this conflicts with 
>stylesheet caching... same with the document() function - to be avoided if 
>possible. Think about this before choosing a direction.
>

I have been looking for a way to use componetized XSLTs without 
include/import. I see how Forrest uses book2menu which does an inital 
transformation producing a new result which is then transformed again. 
Is this considered the correct way to handle component XSLT?

Someone on the user list suggested that I use a pipeline to aggregate 
the XSLT, is there an example or thread you can point me to (I cannot 
find info and can't find it in my hacking)?

At this time, I am seeing this as a perfect job for include or import. I 
assume the problem is that it is considered combining concerns. But 
performing multiple transformations, all the while producing new XML for 
the next transformation seems confusing, especially if there were 
several XSLT components.

I must be missing something. What is the best (Forrest) way to bring 
together component XSLT?

thanks for any info,
-Rob

Re: [RT] XSL structure across projects -- was -->Re: HTML/CSS and graphics

[Steven Noels <st...@outerthought.org>]

On Thu, 23 May 2002, Robert Koberg wrote:

> nevermind... I am ready the docs and checking out the directories - my 
> questions are being answered... sorry for the bother

There are some interesting thoughts in it however, so let me please try to 
comment on them.

> > Will  xml.apache.org projects create their own look and feel? Will all 
> > xml.apache.org projects use the same XSL?

One of the design goals is to have a consistent look & feel for the entire 
XML apache site, so yes, let's assume this. I am preparing a forrest.xml 
descriptor file however, and I am assuming we have non-Forrest 
documentation parts, too (static HTML, i.e. JavaDoc as long as we don't do 
something with it ourselves). Another option would be that projects can 
choose their own skin, but that's in contrast with the original goals. 
Anyone comments on that? What about non-XML Apache projects?

My position would be to say: they have to build a Forrest *skin* if they 
don't like what we provide - not just a loose collection of XSLT 
stylesheets. We have to make sure skins external to Forrest can be used, 
too.

> > If used across all xml-projects, and if they create their own L&F, 
> > what can they change (just CSS? XSL?)?

See above. Skin will be the unit of containment.

> > If they can create their own XSLT, perhaps there should be 
> > xml-apache-rules (already in place?) about xsl:include vs. xsl:import 
> > and/or using a priority attribute on a template rule to override the 
> > base set of XSL.

We should be cautious on xsl:import/include since this conflicts with 
stylesheet caching... same with the document() function - to be avoided if 
possible. Think about this before choosing a direction.

> > -- xsl:include used for things that should never be changed (examples: 
> > copyright, nav)
> > -- xsl:import used for things that can be overriden
> > -- or, perhaps just have the project create a high priority on a 
> > template rule so they override the base set. This makes me think of 
> > another question:
> > Is there some facility in place (or planned) to check a project 
> > directory and see if they have XSL that should be used to override the 
> > base set?

As above, I will add a skin parameter to forrest.xml to addresses this.

> > -- (perhaps this has already been said??) I suggest including a 
> > 'global_definitions.xsl' (or named whatever) from each of the project 
> > sites into a base set of XSL. A project has control over the file and 
> > can include/import/prioritize anyway they want - within the rules.
> > -- there would also be a global_defintions.xsl for each of the 
> > projects in the base set of XSL. These import/include all of the 
> > common XSL. make sense?
> >

</Steven>

Re: [RT] XSL structure across projects -- was -->Re: HTML/CSS and graphics

[Robert Koberg <ro...@koberg.com>]

nevermind... I am ready the docs and checking out the directories - my 
questions are being answered... sorry for the bother

-Rob

Robert Koberg wrote:

> Hi all,
>
> Bert Van Kets wrote:
>
>>
>> I volunteered for this job.  What are your ideas on this task?
>
>
> ------- General XSL Structure ---------
>
> Will  xml.apache.org projects create their own look and feel? Will all 
> xml.apache.org projects use the same XSL?
> If used across all xml-projects, and if they create their own L&F, 
> what can they change (just CSS? XSL?)?
> If they can create their own XSLT, perhaps there should be 
> xml-apache-rules (already in place?) about xsl:include vs. xsl:import 
> and/or using a priority attribute on a template rule to override the 
> base set of XSL.
> -- xsl:include used for things that should never be changed (examples: 
> copyright, nav)
> -- xsl:import used for things that can be overriden
> -- or, perhaps just have the project create a high priority on a 
> template rule so they override the base set. This makes me think of 
> another question:
> Is there some facility in place (or planned) to check a project 
> directory and see if they have XSL that should be used to override the 
> base set?
> -- (perhaps this has already been said??) I suggest including a 
> 'global_definitions.xsl' (or named whatever) from each of the project 
> sites into a base set of XSL. A project has control over the file and 
> can include/import/prioritize anyway they want - within the rules.
> -- there would also be a global_defintions.xsl for each of the 
> projects in the base set of XSL. These import/include all of the 
> common XSL. make sense?
>
> what do you think?
>
> -Rob
>
>
>
>
>
>
>
>