forrest-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <cross...@apache.org>
Subject Re: Convert xdoc v10 to v20
Date Fri, 05 May 2006 04:25:15 GMT
Web Maestro Clay wrote:
> David Crossley wrote:
> >Web Maestro Clay wrote:
> >>- had to replace <code> with [code-FIXME] since it's not in document-
> >>v10.dtd
> >
> >It is in our version of that old DTD.
> 
> BTW, it's in my version of the DTD, but that still doesn't explain  
> why I needed to '-FIXME' it. I don't understand why. All I know is I  
> didn't get that error after I changed it from <code> to [code-FIXME]

Do your original documents validate against their
own version of the document-v10.dtd?

BTW, i glanced at the differences between your version
and Forrest's version of the document-v10 DTD and they
seem identical (except now allow "figure" in "sections").

> >>- had to pepper a couple of other '-FIXME' items (faq.html, etc.)
> >>
> >>PROBLEMS
> >>==========
> >>1. Unfortunately it appears document-v13 files were *not* generated
> >>in build/site.xml (it looks like it merely passed the document-
> >>v10.xml versions across). It'd be great to get v13 files, so I can
> >>move forward with better compatibility.
> >
> >Ah, drat. The proper document type declaration with
> >a Public Identifier is probably needed. Try it as described
> >below by adding one Batik xdoc to a fresh seed site
> >and set its Public Identifier.
> ><!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.0//EN"  
> >"document-v10.dtd">

The main point about that is that Forrest can then use
the powerful SourceTypeAction (content aware pipelines)
where it responds to the Public Identifier and then
Forrest knows how to transform each different document
type.
http://forrest.apache.org/docs/dev/cap.html

> >That will cause it to use Forrest's own DTDs.
> >Try it in 'forrest run' or set the validation
> >off in forrest.properties file.
> 
> That worked! Cool!

However if you don't have valid input docs then
i suppose that you might lose some info.

              ---oOo---

I can see another solution for you. That SourceTypeAction
can also respond to the <document> element and other
features of the input instances such as namespaces.
It is really powerful.

Forrest does not use the "document-element" detection,
so you could use it.

Go back to your original document type declarations
using the System Identifier. This will enable Forrest
to use your local copies of the DTDs at xdocs/dtd/*
(Only necessary if the DTDs are too different.)

In main/webapp/forrest.xmap add another match and
transformer handler. Forrest will not detect your
documents with its existing sourcetype matches
and will fall through to your new catchall.

Here is the diff (trimmed a little) against today's trunk:
===================================================================
--- forrest.xmap        (revision 398540)
+++ forrest.xmap        (working copy)
@@ -96,6 +96,9 @@
         <sourcetype name="howto-v20">
           <document-declaration public-id="-//APACHE//DTD How-to V2.0//EN" />
         </sourcetype>
+        <sourcetype name="document-v10-clay">
+          <document-element local-name="document" />
+        </sourcetype>
       </map:action>
@@ -122,6 +125,10 @@
           <map:when test="document-v10">
             <map:transform src="{lm:transform.docv10.docv11}" />
           </map:when>
 
+          <map:when test="document-v10-clay">
+            <map:transform src="{lm:transform.docv10.docv11}" />
+          </map:when>
+
           <map:when test="document-v20a">
             <map:transform src="{lm:transform.docv20.docv12}" />
           </map:when>
===================================================================

That sourcetype name="document-v10-clay" gives you the
ability to add additional transformers for particular
elements that you might need transformed. Otherwise
we could have just said sourcetype name="document-v10"
and it would use the existing set of transformers shown
just above yours.

Why "transform.docv10.docv11"? No problem: docv11
is essentially the same as docv13, some restrictions
were relaxed and every element can have a @class attr.

> Unfortunately, it kept the <anchor id="yatayata"/>  
> line so it looks like:
> 
>     <anchor id="systemRequirements"/>
>     <section><title>System Requirements</title>
>       <p>
>         Batik requires the following systems to be already
>         installed in your system:
>       </p>
>       <ul>
>         <li><strong>Java Virtual Machine</strong>
>           A Java 1.3 or greater compatible virtual machine must be  
> present.
>         </li>
>       </ul>
>     </section>
> 
> IIUC, that needs to be changed to:
> 
>     <section id="systemRequirements"><title>System Requirements</title>
>       <p>
>         Batik requires the following systems to be already
>         installed in your system:
>       </p>
>       <ul>
>         <li><strong>Java Virtual Machine</strong>
>           A Java 1.3 or greater compatible virtual machine must be  
> present.
>         </li>
>       </ul>
>     </section>

Yes. How are they done in your source doc?
Perhaps you will need to edit your source documents to
have @id on each section rather than anchor.

-David

Mime
View raw message