cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Ball <ba...@webslingerZ.com>
Subject Re: [c2] problems with xincludesaxconnector
Date Tue, 01 May 2001 13:44:47 GMT
On Tue, 1 May 2001, giacomo wrote:

> > my issues:
> >
> > 1. why should this be a saxconnector instead of a filter?
>
> What's a filter? If you mean a Transformer then it's because a
> transformer doesn't gets to a sitemap instance to request internal
> resources (and I have to say I like the way it is now because I don't
> think it make sense to sitemap components to have a instance of a
> sitemap at hand). With the SAXConnectors C2 has transparent XInclude
> capability which I think is totally cool.

i mean transformer, yes. i still don't see why it's necessarily desirable
to do automatic xinclude processing, but i'm happy to use the
NullSAXConnector. it bothers me that we have two pieces of code that do
the same thing though - that's a maintenance hassle if nothing else.

> > 2. the schema upon which it operates doesn't conform to the official
> > xinclude spec, but it operates on the official xinclude namespace. one or
> > the other needs to change. specifically, at the least, the src attribute
> > should be an href attribute and the ns and prefix attributes don't exist.
>
> The ns attribute is a suggestion from Stefano and the prefix comes from
> the recent sitemap aggregate discussion. I think both (ns and prefix)
> are totally necessary because you cannot prevent name collisions without
> it. Stefano also suggest to promote that to the w3c (but I think nobody
> took it there)

i don't think either of these attributes is necessary, honestly, if you
want a default namespace for the included document and you don't think it
has one already, you can set one for the xinclude element itself:

<xinclude:include href="foo" xmlns="http://example.com/xml/foo/1.0"/>

using the standard namespace attribute semantics. in any case, i'm adamant
that if we don't conform to the xinclude semantics, then we must operate
on another namespace.

- donald


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


Mime
View raw message