XLink ? Embedding Documents

[Nathan Pride <np...@wavo.com>]

Hi Folks

    I have an xml file which embeds another xml in it. This is the code:

<?xml version="1.0"?>
<?xml-stylesheet href="http://localhost/stylsheet.xsl" type="text/xsl"?>

<?cocoon-process type="xslt"?>

<!DOCTYPE mymerge [
 <!ENTITY story SYSTEM "http://localhost/my.xml">
 ]>

<mymerge> &story; </mymerge>

I was under the impression that Cocoon checks all dependencies for
changes before using a cached copy, unfortunately it doesn't seem to
consider the ENTITY a dependency. When the my.xml files is modified
Cocoon still uses the cached copy. Is there a solution to my problems.

    Which brings me on to XLink or similar beasts any know if cocoon is
capable of dealing with these specs, and if  so how.

    Thanks

    Nathan

Re: XLink ? Embedding Documents

[Nathan Pride <np...@wavo.com>]

Thanks for the help Stefano,

Here is the problem I'm trying to solve, I have thousands of xml documents
(two DTD's, a document and an RDF) I would like to bind a given xsl style
sheet to a document or a collection of documents, I do not have the luxury
of modifying the original document to include the style sheet and processing
information.

My ENTITY hack attempt was close but failed.

A producer with a stylesheet argument didn't strike me as a particularly
elegant solution, and I don't know how this would work with the caching. By
using the producer I don't see how I could combine the information from the
document and it's corresponding rdf.

I don't know if or how I could use DCP to achieve the same results.

I feel I frustratingly close to a solution but I can see it yet, can some
please pull back the curtains !

    Thanks

    Nathan

Stefano Mazzocchi wrote:

> Nathan Pride wrote:
> >
> > Hi Folks
> >
> >     I have an xml file which embeds another xml in it. This is the
> > code:
> >
> > <?xml version="1.0"?>
> > <?xml-stylesheet href="http://localhost/stylsheet.xsl"
> > type="text/xsl"?>
> > <?cocoon-process type="xslt"?>
> >
> > <!DOCTYPE mymerge [
> >  <!ENTITY story SYSTEM "http://localhost/my.xml">
> >  ]>
> >
> > <mymerge> &story; </mymerge>
> >
> > I was under the impression that Cocoon checks all dependencies for
> > changes before using a cached copy, unfortunately it doesn't seem to
> > consider the ENTITY a dependency. When the my.xml files is modified
> > Cocoon still uses the cached copy. Is there a solution to my problems.
>
> well, no, not a really clean one. From the Cocoon's point of view, the
> XML is one big file, even if this is generated by including many
> "pieces" around.
>
> >     Which brings me on to XLink or similar beasts any know if cocoon
> > is capable of dealing with these specs, and if  so how.
>
> XLink is, today, a client side specification now that they removed the
> "parsed" attribute (as in the last working draft). Much like a web
> server doesn't care about <a href=""> tags but the browser does.
>
> but (there is always a "but" someplace), Cocoon will need to propose an
> extention to XLink (what we call "soft links") that allows one resource
> to connect to another in a soft way, to allow two documents to connect
> even after they are processed and pre-generated, but this is _NOT_
> something you should care about now.
>
> So, as far as caching goes, the XML parser should return to us a list of
> the external entities, or, we should make Cocoon behave as a DTD parser
> to check them for us.
>
> Of course, either cases, we are bound to a particular XML parser
> implementation since no XML API expresses these external entities.
>
> What to know all of it?
>
> Well, I think one should NEVER use a DTD in a XML document. Never. the
> DTD is the SGML leftover and we should forget about those things and
> move on.
>
> There is a proposal almost dying in W3C, it's called XInclude and should
> allow one to make one document hardlinked with other documents, but
> externally... after the parsing. This would allow us to know what's
> going on.. something like
>
>  file -> parser -> DOM -> include manager -> DOM
>
> instead of simply
>
>  file -> parser -> DOM
>
> which is a black box from Cocoon's perspective.
>
> Anyway, we have to stick with what we have right now...
>
> --
> Stefano Mazzocchi      One must still have chaos in oneself to be
>                           able to give birth to a dancing star.
> <st...@apache.org>                             Friedrich Nietzsche
> --------------------------------------------------------------------
>  Come to the first official Apache Software Foundation Conference!
> ------------------------- http://ApacheCon.Com ---------------------