cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <cross...@indexgeo.com.au>
Subject Re: various copies of DTDs within Cocoon
Date Wed, 24 Apr 2002 08:44:00 GMT
Piroumian Konstantin wrote:
> > David Crossley wrote:
> > 
> > A few weeks ago someone committed changes to
> > src/documentation/xdocs/dtd/document-v10.dtd
> > However please remember that there are two copies
> > of the DTDs ...
> <snip/>
> > This does raise some issues though. When we rely on
> > the entity resolver, then it becomes core functionality
> > (build docs would fail without it). At the moment, entity
> > resolver is not listed as core.
> 
> I have a little off-topic question related to this topic ;)

Not off-topic at all. This is what i was indicating. Any outside
tool that is used to edit the docs in-place would need to be
able to use an entity resolver, and Cocoon would rely on its own.

> Usually, I use XML Spy to edit xdocs. It's very useful to have DTDs attached
> to editing files, cause XML Spy provides hints for elements and attributes
> as you type and performs validity checks. But, unfortunately, it does not
> support local entity catalogs,

Then you should get a better tool. That is a flippant answer
i know. However, we must strive. The interesting thing is that
XML-Spy provide sponsorship for the OASIS web pages, or at
least Robin Cover's excellent CoverPages at oasis-open.org/cover
and Altova is a member of OASIS. Perhaps they have an
undocumented feature (see below).
 
> so, now when Cocoon docs contain links to
> DTDs that does not correspond to their physical location locally I can't use
> all that useful features without copying them somewhere accessible or
> changing the declaration.
>
> So, I'd like to know what's the correct way of managing such situations. Can
> I just setup a local catalog and use SYSTEM entities or my editing tool
> should support catalogs natively? 

Either way you would need to set up an OASIS Catalog
(just use the catalog file that comes with Cocoon). Tools
such as XMetaL have native support and they still need
you to configure the catalog file, obviously.

It all depends on your tools. If it doesn't support it natively then
it may support it via a command-line switch. For stylesheet work
i use Saxon from the command-line. It has a -r option which lets
Saxon use the same resolver java classes that we do in Cocoon.

> Thanks for all hints in advance.
> 
> Regards,
>   Konstantin Piroumian

OK. This is why i did not just rush in and rationalise Cocoon
CVS to have only one copy of DTDs to avoid confusion.
We need to discuss this issue.

Perhaps it would be better to leave the two copies in their
respective places and just live with it until some future
technology takes over down the track. The trouble is that
there are even more DTD copies scattered across our CVS and
out-of-sync (e.g. webapp/samples/tutorial/ and webapp/tutorial/).

Nicola, i expect you have probably needed to deal with
a similar issue in Centipede and Forrest. Any clues?
--David

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message