You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@forrest.apache.org by Clay Leeds <cl...@medata.com> on 2004/11/06 01:05:02 UTC

convert to document-v20.dtd

I see there are some tools, but I'm confused:

[clay@Clay-Leeds-Computer forrest]$ find . -iname *todoc*
...
./main/webapp/resources/stylesheets/docv10todocv11.xsl
./main/webapp/resources/stylesheets/docv20todocv12.xsl
./main/webapp/resources/stylesheets/docv20todocv13.xsl

I want to convert from docv12todocv20 but there doesn't seem to be 
one... are those last two just poorly named? Who would want to go 
backwards? Or is this a case of "maybe 'someone' can do a PATCH"? ;-)

(NOPE! I just checked, and I see that those do actually convert from 
docv20 to docv13/12... hmmm!) Looks like we need someone to make some 
new files...

:-)

Web Maestro Clay
-- 
Clay Leeds - <cl...@medata.com>
Webmaster/Developer - Medata, Inc. - <http://www.medata.com/>
PGP Public Key: <https://mail.medata.com/pgp/cleeds.asc>


Re: convert to document-v20.dtd

Posted by Ross Gardler <rg...@apache.org>.

Clay Leeds wrote:
> On Nov 7, 2004, at 6:26 PM, Rick Tessner wrote:
> 
>> Dave Brondsema wrote:
>>
>>> Maybe because v13 is still our intermediate format, so internally we 
>>> "downgrade" v20 sources to v13.  I don't know... parts of that idea 
>>> seem right, but it seems like we'd also lose some information if we 
>>> downgrade v20 to be a valid v13 document.
>>
>>

<snip/>

>> In addition, with the use of XHTML soon-to-be the intermediate format, 
>> it just seemed the best decision at the time to keep v1.x as the 
>> intermediate format.
>>

<snip/>

>> All in all, it appeared to be cleaner in the interim to use v13 rather 
>> than v20 as the intermediate.
>>
>> Hope this helps. :)
> 
> 
> It helps, but it makes me wonder... What is the purpose of 
> document-v20.dtd, if all content is going to be converted back to 
> doc-v13 compliant anyway.

If you write your docs in v2.0 then you are one small step closer to 
XHTML, meaning there is less to do on the user end when we do move to 
XHTML. That is users are not encouraged to use the tags that have gone, 
i.e. <link..> <fork..> etc.

Ross

Re: convert to document-v20.dtd

Posted by Clay Leeds <cl...@medata.com>.
On Nov 7, 2004, at 6:26 PM, Rick Tessner wrote:
> Dave Brondsema wrote:
>> Maybe because v13 is still our intermediate format, so internally we 
>> "downgrade" v20 sources to v13.  I don't know... parts of that idea 
>> seem right, but it seems like we'd also lose some information if we 
>> downgrade v20 to be a valid v13 document.
>
> Hi all,
>
> Yup, Dave is correct here.  When I added the class attribute to v12 to 
> create v13 and also did the v20 at the same time, I was looking at 
> making v20 the intermediate format.
>
> That just seemed to touch soooo many different bits, it looked like 
> the best way to address this was to create a transformation back to 
> v1.x.
>
> In addition, with the use of XHTML soon-to-be the intermediate format, 
> it just seemed the best decision at the time to keep v1.x as the 
> intermediate format.
>
> It's actually cleaner in terms of information loss going from v20 to 
> v1.x, believe it or not.  That's because, in going from v13 to v20, 
> the changes were:
>
>   1. Renamed <link>  to <a>.
>   2. Removed <fork> and <jump> in favour of the <a> element. See
>      demonstration using class attribute on links.
>
> [ The above taken from 
> http://forrest.apache.org/docs/document-v20.html#changes-20 ]
>
> Conversion to v20 from v13 can result in loss of information since 
> <fork> and <jump> were deprecated in v20.  It's simple in taking the 
> <a> element in v20 and converting it to <link>.
>
> All in all, it appeared to be cleaner in the interim to use v13 rather 
> than v20 as the intermediate.
>
> Hope this helps. :)

It helps, but it makes me wonder... What is the purpose of 
document-v20.dtd, if all content is going to be converted back to 
doc-v13 compliant anyway.

Web Maestro Clay
-- 
Clay Leeds - <cl...@medata.com>
Webmaster/Developer - Medata, Inc. - <http://www.medata.com/>
PGP Public Key: <https://mail.medata.com/pgp/cleeds.asc>


Re: convert to document-v20.dtd

Posted by Rick Tessner <ri...@onnadayr.ca>.
Dave Brondsema wrote:

> Maybe because v13 is still our intermediate format, so internally we 
> "downgrade" v20 sources to v13.  I don't know... parts of that idea seem 
> right, but it seems like we'd also lose some information if we downgrade 
> v20 to be a valid v13 document.

Hi all,

Yup, Dave is correct here.  When I added the class attribute to v12 to 
create v13 and also did the v20 at the same time, I was looking at 
making v20 the intermediate format.

That just seemed to touch soooo many different bits, it looked like the 
best way to address this was to create a transformation back to v1.x.

In addition, with the use of XHTML soon-to-be the intermediate format, 
it just seemed the best decision at the time to keep v1.x as the 
intermediate format.

It's actually cleaner in terms of information loss going from v20 to 
v1.x, believe it or not.  That's because, in going from v13 to v20, the 
changes were:

   1. Renamed <link>  to <a>.
   2. Removed <fork> and <jump> in favour of the <a> element. See
      demonstration using class attribute on links.

[ The above taken from 
http://forrest.apache.org/docs/document-v20.html#changes-20 ]

Conversion to v20 from v13 can result in loss of information since 
<fork> and <jump> were deprecated in v20.  It's simple in taking the <a> 
element in v20 and converting it to <link>.

All in all, it appeared to be cleaner in the interim to use v13 rather 
than v20 as the intermediate.

Hope this helps. :)

-- 
rick@onnadayr.ca
IT Firefighting and Prevention

Re: convert to document-v20.dtd

Posted by Dave Brondsema <da...@brondsema.net>.
Clay Leeds wrote:
> On Nov 5, 2004, at 4:38 PM, David Crossley wrote:
> 
>> Clay Leeds wrote:
>>
>> 'svn log docv20todocv13.xsl' reveals that they were part
>> of issues FOR-174 which might provide some clues. When you
>> find out, we should patch the head of those *.xsl with
>> a brief comment as to purpose.
>>
>> ------
>> Add missing files from revision 23140.
>> Issue: FOR-174
>> Submitted by: Rick Tessner
>> ------
> 
> 
> I saw them, but I couldn't figure out *why* they were needed. As I said 
> previously, I can understand needing to go from 1.2 & 1.3 to 2.0, but 
> not the other way...
> 

Maybe because v13 is still our intermediate format, so internally we 
"downgrade" v20 sources to v13.  I don't know... parts of that idea seem 
right, but it seems like we'd also lose some information if we downgrade 
v20 to be a valid v13 document.

-- 
Dave Brondsema : dave@brondsema.net
http://www.splike.com : programming
http://csx.calvin.edu : student org
http://www.brondsema.net : personal

Re: convert to document-v20.dtd

Posted by Clay Leeds <cl...@medata.com>.
On Nov 5, 2004, at 4:38 PM, David Crossley wrote:
> Clay Leeds wrote:
>> I see there are some tools,
>
> Yes some old ones, probably not needed.
>
> Some recent ones which are probably still used
> ... do grep *.xmap to find where.
>
> Some still needed. Thanks for doing
> http://issues.cocoondev.org//browse/FOR-352
> "New conversion tools (docv12 + docv13 => docv20)"

Cheers!

>> but I'm confused:
>>
>> [clay@Clay-Leeds-Computer forrest]$ find . -iname *todoc*
>> ...
>> ./main/webapp/resources/stylesheets/docv10todocv11.xsl
>> ./main/webapp/resources/stylesheets/docv20todocv12.xsl
>> ./main/webapp/resources/stylesheets/docv20todocv13.xsl
>>
>> I want to convert from docv12todocv20 but there doesn't seem to be
>> one... are those last two just poorly named? Who would want to go
>> backwards? Or is this a case of "maybe 'someone' can do a PATCH"? ;-)
>>
>> (NOPE! I just checked, and I see that those do actually convert from
>> docv20 to docv13/12... hmmm!)
>
> 'svn log docv20todocv13.xsl' reveals that they were part
> of issues FOR-174 which might provide some clues. When you
> find out, we should patch the head of those *.xsl with
> a brief comment as to purpose.
>
> ------
> Add missing files from revision 23140.
> Issue: FOR-174
> Submitted by: Rick Tessner
> ------

I saw them, but I couldn't figure out *why* they were needed. As I said 
previously, I can understand needing to go from 1.2 & 1.3 to 2.0, but 
not the other way...

>> Looks like we need someone to make some
>> new files...
>>
>> :-)
>
> I am confused, please explain.

Sorry. Humor can be tough to get through on this here mailing list 
thing:

   Looks like we need someone (insert 'someone like me!' here)
   to make some new files...

Immediately after I wrote that, I went ahead and made those files. I 
don't know how they'll be used, though. It would be nice for someone 
(probably *not* me :-)) to enable /forrest convert-docv13todocv20/ to 
convert the files.

> You also say above "want to convert from docv12todocv20".
> I wonder if a "docv1todocv20" would handle v1.3 and v1.2

It should! That would be even better! I guess we just need to add the 
@class.

> The other issue is how these tools would get used.
> In the past we have used an Ant build task to do
> batch conversions of xdocs and store the resulting
> set of documents into a build directory. This was
> developed early in Forrest to transform the Cocoon
> documentation to upgraded DTDs.

Looks like FOR-174 was done in July 2004 so it's not too old.

> I have a feeling that we left that old work in the
> CVS Attic of the old "xml-forrest" CVS. Searching
> the mail archives would find it. Diana Shannon
> was the main driver. One thread is:
>
>> From: Diana Shannon <shannon<AT>apache.org>
>> To: forrest-dev<AT>xml.apache.org
>> Subject: Cocoon docs transition report
>> Date: 17 Jun 2002 23:51:34 -0400

Glad to be of service...

Web Maestro Clay
-- 
Clay Leeds - <cl...@medata.com>
Webmaster/Developer - Medata, Inc. - <http://www.medata.com/>
PGP Public Key: <https://mail.medata.com/pgp/cleeds.asc>


Re: convert to document-v20.dtd

Posted by David Crossley <cr...@apache.org>.
(Moved over from user list.)

Clay Leeds wrote:
> I see there are some tools,

Yes some old ones, probably not needed.

Some recent ones which are probably still used
... do grep *.xmap to find where.

Some still needed. Thanks for doing
http://issues.cocoondev.org//browse/FOR-352
"New conversion tools (docv12 + docv13 => docv20)"

> but I'm confused:
> 
> [clay@Clay-Leeds-Computer forrest]$ find . -iname *todoc*
> ...
> ./main/webapp/resources/stylesheets/docv10todocv11.xsl
> ./main/webapp/resources/stylesheets/docv20todocv12.xsl
> ./main/webapp/resources/stylesheets/docv20todocv13.xsl
> 
> I want to convert from docv12todocv20 but there doesn't seem to be 
> one... are those last two just poorly named? Who would want to go 
> backwards? Or is this a case of "maybe 'someone' can do a PATCH"? ;-)
> 
> (NOPE! I just checked, and I see that those do actually convert from 
> docv20 to docv13/12... hmmm!)

'svn log docv20todocv13.xsl' reveals that they were part
of issues FOR-174 which might provide some clues. When you
find out, we should patch the head of those *.xsl with
a brief comment as to purpose.

------
Add missing files from revision 23140.
Issue: FOR-174
Submitted by: Rick Tessner
------

> Looks like we need someone to make some 
> new files...
> 
> :-)

I am confused, please explain.

You also say above "want to convert from docv12todocv20".
I wonder if a "docv1todocv20" would handle v1.3 and v1.2

The other issue is how these tools would get used.
In the past we have used an Ant build task to do
batch conversions of xdocs and store the resulting
set of documents into a build directory. This was
developed early in Forrest to transform the Cocoon
documentation to upgraded DTDs.

I have a feeling that we left that old work in the
CVS Attic of the old "xml-forrest" CVS. Searching
the mail archives would find it. Diana Shannon
was the main driver. One thread is:

> From: Diana Shannon <shannon<AT>apache.org>
> To: forrest-dev<AT>xml.apache.org
> Subject: Cocoon docs transition report
> Date: 17 Jun 2002 23:51:34 -0400

-- 
David Crossley


Re: convert to document-v20.dtd

Posted by David Crossley <cr...@apache.org>.
I moved this technical discussion to the dev list
same Subject.

-- 
David Crossley