forrest-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <cross...@apache.org>
Subject Re: Sitemap dot xmap sourcetyping
Date Wed, 08 Jun 2005 01:43:48 GMT
Maurice Lanselle wrote:
> David Crossley said the following on 07/06/2005 03:46:
> >Maurice Lanselle wrote:
> >>Ross Gardler said the following:
> >>
> >>>However, you should avoid limiting the URL space of your application 
> >>>by requiring a given file type to have a given filename or path. This 
> >>>can result in false matches. You should use the SourceTypeResolver, 
> >>>for an example of how see 
> >>>http://svn.apache.org/viewcvs.cgi/forrest/trunk/plugins/org.apache.forrest.plugin.input.simplified-docbook/input.xmap?view=markup

> >>>for an example of how to do this.
> >>>
> >>I totally buy your point about not requiring a document type to have a 
> >>given file name or path.  Since I'm trying to use or produce xml files 
> >>which have the ".xml" extension rather than something more distinctive, 
> >>I would like Forrest to choose the stylesheet on the basis of the 
> >>doctype, perhaps using a catalog (like for resolving DTDs...why not 
> >>catalogs for xsl?).  ...
> >
> >No, the "catalog entity resolver" addresses a separate part of the issue.
> >It sounds like we need to enhance the documentation. Source Type Resolver,
> >actually called "SourceTypeAction (content aware pipelines)" [2] is one of
> >the key features of Forrest and so we need to explain it better.
> >
> >Lets first correct your comment about "catalog". Its use is to create
> >an efficient system for xml documents that declare a DTD so that the
> >xml parser gets a local copy rather than going across the network.
> >
> Sorry if I wasn't clear.  When I referred to using *a* catalog (not 
> *the* catalogs used for validation resolving) I meant just the concept 
> of a look-up table the pipeline could use to identify a 
> document-type-specific handling to apply.

Ah i see. I still had to correct your comments, otherwise other users
would be seriously confused. I was. Anyway, it is good because it
provides a chance to better explain these facilities.

> >Now back to Source Type Action ... It is a Cocoon sitemap component that
> >peeks at the top-part of a document to look for hints about the type
> >of the document. 
> >
> >[1] http://forrest.apache.org/docs/your-project.html#sitemap.xmap 
> >[2] http://forrest.apache.org/docs/cap.html
> >
> >These are the available methods:
> >document-declaration
> >document-element and namespace
> >processing-instruction
> >w3c-xml-schema
>
> While reading the SourceTypeAction doc, a couple of questions came to 
> mind.  I think it would be helpful to find their answers in that doc. :

I hope that you started at reference #1 and followed the background
reading. What this is showing is that we need much better documents
about our SourceTypeAction and that Cocoon needs a very high-level
document to explain its sitemap. Perhaps the Cocoon documents that
we refer to are too technical.

Sorry, i don't have much time today, so only quick comments.

The Cocoon sitemap is not a logic-based programming language.
There are no constructs like boolean AND/OR between the
sitemap elements. Its language is more like XSL.

> 1) What is the appropriate way to construct "OR" classification rules?  
> For instance, the document-element may return a local-name, a namespace, 
> or both.
>
> Should one define two (or more) rules with the same sourcetype 
> name, such as...
> 
> <sourcetype name="foo">
>    <document-element local-name="foo">
> </sourcetype>
> <sourcetype name="foo">
>    <document-element namespace="bar">
> </sourcetype>
> 
> or a single rule with a list of alternative conditions, such as...
> 
> <sourcetype name="foo">
>    <document-element local-name="foo">
>    <document-element namespace="bar">
> </sourcetype>
> 
> or is there some other syntax?

One way would be to assign different sourcetype@name attributes
in the <map:action> and then in the <pipelines> part of the sitemap
you would have separate matches which just repeat the same processing.
e.g.

  <sourcetype name="foo">
    <document-element local-name="foo">
  </sourcetype>
  <sourcetype name="bar">
    <document-element namespace="bar">
  </sourcetype>
...
...
      <map:when test="foo">
       <map:transform
          src="{project:resources.stylesheets}/foobar2document.xsl" />
      </map:when>
      <map:when test="bar">
       <map:transform
          src="{project:resources.stylesheets}/foobar2document.xsl" />
      </map:when>
...

You could also search the Cocoon documentation and wiki.
You might find other examples of <map:select> that show
better uses of the <map:when test="...
perhaps that test can be more complete.

> 2) How does one construct "AND" classification rules?
> 
> <sourcetype name="foo">
>    <document-element local-name="foo"> && <document-element namespace="bar">
> </sourcetype>

I don't know if that is possible or needed. Perhaps there is another way.
It would be better if you provided an actual use-case.

--David

> These are not urgent (for me), but I expect they will be wanted sooner 
> or later.
> 
> Regards and thanks for the communication,
> Maurice
> 
> >If you use the first technique, then the parser needs to go retrieve
> >the DTD from across the network. Hence the need for Catalog Entity 
> >Resolver.
> >
> >I don't use "w3c-xml-schema" so i am not sure if the parser is forced
> >to locate the actual schema. I gather that it doesn't. Therefore you
> >don't need to mess about with catalogs.
> >
> >Now if there are Java people out there listening, then perhaps you would
> >like to enhance the Source Type Action to enable other methods. It is in
> >the Forrest source at main/java/org/apache/forrest/sourcetype
> >
> >--David
> >
> > 
> >
> >>...  It looks like that is what happens in the 
> >><map:resources> group in the example you pointed me to (below).  My 
> >>first attempt to *bend* it to my purpose failed, however: "Type 
> >>'sourcetype' does not exist for 'map:pipeline' at..." when I replaced
> >>
> >><map:pipeline>
> >> <map:match pattern="**Resume.xml">
> >>by
> >><map:pipeline type="sourcetype" src="{src}">
> >>      <map:select type="parameter">
> >>        <map:parameter name="parameter-selector-test" 
> >>value="{sourcetype}" />
> >>        <map:when test="Resume">
> >>
> >>But one thing at a time...xslt first, then plugin/resolving.
> >>
> >>Many thanks,
> >>Maurice
> >>   
> >>
> >
> > 
> >

Mime
View raw message