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 [EMAIL PROTECTED] 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 > >> > >> > > > > > >
