From forrest-dev-return-4751-apmail-xml-forrest-dev-archive=xml.apache.org@xml.apache.org Thu Feb 06 08:10:03 2003 Return-Path: Delivered-To: apmail-xml-forrest-dev-archive@xml.apache.org Received: (qmail 73232 invoked by uid 500); 6 Feb 2003 08:10:03 -0000 Mailing-List: contact forrest-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: forrest-dev@xml.apache.org Delivered-To: mailing list forrest-dev@xml.apache.org Received: (qmail 73222 invoked from network); 6 Feb 2003 08:10:02 -0000 Received: from fep01.tuttopmi.it (HELO fep01-svc.flexmail.it) (212.131.248.100) by daedalus.apache.org with SMTP; 6 Feb 2003 08:10:02 -0000 Received: from apache.org ([80.204.154.181]) by fep01-svc.flexmail.it (InterMail vM.5.01.05.09 201-253-122-126-109-20020611) with ESMTP id <20030206081010.UJAO12636.fep01-svc.flexmail.it@apache.org> for ; Thu, 6 Feb 2003 09:10:10 +0100 Message-ID: <3E42185F.6050703@apache.org> Date: Thu, 06 Feb 2003 09:10:07 +0100 From: Nicola Ken Barozzi Reply-To: nicolaken@apache.org Organization: Apache Software Foundation User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: forrest-dev@xml.apache.org Subject: Re: Xinclude and (in)validation References: <3E41A232.7050101@apache.org> <3E41A5A9.8020500@yahoo.de> <3E41A729.2080108@apache.org> <3E41AA4C.4030403@apache.org> <20030206013412.GA6096@expresso.localdomain> In-Reply-To: <20030206013412.GA6096@expresso.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Jeff Turner wrote, On 06/02/2003 2.34: > On Thu, Feb 06, 2003 at 01:20:28AM +0100, Nicola Ken Barozzi wrote: > >>Replying myself. Found a doc that explains it. >>http://www.xml.com/pub/a/2002/07/31/xinclude.html?page=2 > > ... ... >>Possibility: plug in an xinclude step before the validation. There is an >>xinclude task somewhere, if not we can make it. > > Problem is, whatever tool does the xinclude preprocessing will need to > use a parser, and when that parser encounters the DOCTYPE declaration it > will try to validate the XML :) Even non-validating? IIRC when you have a DTD, it always reads it, but for entities. Validation is a further step. > That is, unless the xinclude tool uses XNI directly, or fiddles with the > bytestream before and after parsing: > > http://doctypechanger.sourceforge.net/ > > I think the best solution is to modify the DTD to allow xi:include. The > Docbook book has some info on this process: > > http://docbook.org/tdg/en/html/ch05.html > > I don't think there are any better solutions, so long as we're hanging > onto DTDs. Even the latest version of Docbook has declared SVG, MathML > and HTML forms in the DTD, rather than abandon DTDs altogether. Ahhh. Well, I think that including xinclude ;-) in the DTDs is a reasonable thing, and one of the possible solutions. The fact is that I don't like much fiddleing with other DTDs, and since users might want to make their own DTD /and/ pretend to have xinclude working, maybe a pre-xinclude step would ease things. Dunno, both seem ok... I'll see if I can do something with a pre-xinclude. Maybe it will just slow down things and be a mess or it will be simply to hard to do, I don't wnat to spend too much time on it, if it takes too much, I'll include it in the DTD. BTW, is everyone ok if I put xinclude in the processing (just to be sure)? -- Nicola Ken Barozzi nicolaken@apache.org - verba volant, scripta manent - (discussions get forgotten, just code remains) ---------------------------------------------------------------------