[izpack-devel] Adding XInclude support

[Matthew Fudge]

Hi Tino,


At the moment I'm planning on supporting all of XInclude apart from XPointer (which allows references to particular infosets (elements) inside the current or other documents)

So anywhere in any of the XML documents used in izpack you can do

<include  href='other.xml'/> 

which will replace the include with the contents of the 'other.xml'. This works for Http/https/file protocols and relative file references(without needing the "file://" bit). It's not that I really need anything apart from relative file references but they come almost for free. It will also support the fallback element (again this is not much use in an installer but not to much effort to add)

In addition I am adding a "fragment" element that can be used as a root node in included documents. This element will be removed when the document is included. This enables included documents to be xml fragments such as a set of field elements to be included in the userInputSpec.xml

XInclude is also recursive in that "include" elements in included documents will also be included.
 

Cheers

Matt


----- Original Message ----
From: Tino Schwarze <berlios.de at tisc.de>
To: izpack-devel at lists.berlios.de
Sent: Wednesday, 12 December, 2007 7:53:01 AM
Subject: Re: [izpack-devel] Adding XInclude support

Hi Matthew,

On Tue, Dec 11, 2007 at 03:47:59AM -0800, Matthew Fudge wrote:

> I'm looking at adding support for a subset of the XInclude
 specification (http://www.w3.org/TR/xinclude/) to IzPack. 
> 
> To make a few projects of mine a bit more modular and maintainable I
 think it would be useful to allow parts of the 
> xml files used by IzPack to be included from other files (and yes
 I've tried using external entities but they are a bit limited
> for my needs)

Which parts do you want to include, in detail?

> The current code is based on a copy of the StdXMLBuilder class that
 has been modified to allow extending classes access to its internal
 state.
> 
> Note that this will not be a full implementation of the XInclude spec
 (I don't have time right now to handle the XPointer stuff properly)
> 
> So some questions: 
> 
> a) Is a change like this likely to be accepted?
> b) namespace support seems really limited in nanoxml when used in
 IzPack. I'm not seeing any. Am I missing something?

We use a rather old version of NanoXML (with some patches too). Because
we opted for small installer size and the new NanoXML is a lot larger
(in terms of JAR size which needs to be included in every installer),
 we
didn't want to switch.

So, yes, there's no namespace support and the parser is very
lightweight. Oh, BTW: We don't use SAX or JAXP because installers
 should
still run on 1.2? or 1.3 JREs.

> c) Is it preferable to make changes to the nanoxml packages or the
 izPack packages. I'm asking because it makes little difference to the
> code and many people prefer to keep third party source as original as
 possible.

I'd go for changing NanoXML. We're not going to upgrade anyway. And if
we do, it will be major changes.

Bye,

Tino.

-- 
www.craniosacralzentrum.de
www.lebensraum11.de
www.spiritualdesign-chemnitz.de

Tino Schwarze * Parkstraße 17h * 09120 Chemnitz
_______________________________________________
izpack-devel mailing list
izpack-devel at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/izpack-devel





      __________________________________________________________
Sent from Yahoo! Mail - a smarter inbox http://uk.mail.yahoo.com