Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 75855 invoked by uid 500); 1 May 2001 13:44:34 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 75841 invoked from network); 1 May 2001 13:44:34 -0000 Date: Tue, 1 May 2001 09:44:47 -0400 (EDT) From: Donald Ball X-Sender: To: Subject: Re: [c2] problems with xincludesaxconnector In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N 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: 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