Re: [Springframework-developer] Include/import directive in XML bean definition files

[Colin S. <col...@ex...>]

+1

jürgen höller [werk3AT] wrote:

>For a start, we need to decide:
>- custom "include" element or XInclude support?
>- Spring 1.1 or 1.2 timeframe?
> 
>I personally prefer external config locations, and consider an "include" element as purely optional feature, particularly given that XML entity includes already work. I don't have a fixed opinion on the implementation strategy yet; if there's no clear consensus on the actual strategy within the next 2 weeks, I vote for moving this to Spring 1.2.
> 
>Juergen
> 
>
>________________________________
>
>Von: spr...@li... im Auftrag von Timo Verhoeven
>Gesendet: Sa 26.06.2004 11:57
>An: spr...@li...
>Betreff: Re: [Springframework-developer] Include/import directive in XML bean definition files
>
>
>
>
>Alef, Jürgen,
>
>I've done some research. The XInclude spec is quite short (in terms of
>the W3C), http://www.w3.org/TR/xinclude/ . Digest:
>
>XInclude transforms the infoset, thus happens after parsing. XInclude
>defines only two elements: include and fallback. Include uses IRIs
>(Internationalized Resource Identifiers, essentially URIs) to reference
>resources. It can import those resources as xml or text. In case of xml
>it can use XPointer to include only portions of the resource.
>
>  
>
>>How does the XInclude stuff retrieve the resources. Will it allow us
>>to specify resources in somewhat the same way as we do now
>>(classpath:, etcetera) and is it possible to integrate this with the
>>resource package we have?
>>    
>>
>
>AFAIK, IRIs/URIs can have application specific form. The XInclude spec
>explicitly says
>
>"The specifics of how an infoset is created are intentionally
>unspecified, to allow for flexibility by implementations and to avoid
>defining a particular processing model for components of the XML
>architecture. Particulars of whether DTD or XML schema validation are
>performed, for example, are not constrained by this specification."
>
>  
>
>>>Sounds plausible. I'm no XML expert, though: How could we make this
>>>work?
>>>      
>>>
>
>We "only" need a simple layer, which processes all XInclude elements of
>the infoset (the parsed XML). I couldn't find a simple black box
>solution, only this:
>
>- XIncluder, http://xincluder.sourceforge.net/ : Seems to be
>unmaintained, not feature complete; nevertheless it's the basis for
>some other projects (XOM, e.g.).
>
>- GNU JAXP, http://www.gnu.org/software/classpathx/jaxp/ : "includes a
>SAX filter that resolves XIncludes, provided no XPointers are used"
>
>- Cocoon XInclude transformer,
>http://cocoon.apache.org/2.1/userdocs/transformers/xinclude-transformer.html :
>Seems to be feature complete, but written for use in cocoon
>
>The Cocoon stuff might be worth reviewing.
>
>BTW, using DTDs for validation has a little drawback: DTDs are not
>namespace aware. Thus an updated Spring DTD for XInclude would force
>the user to use a fixed prefix (xi, e.g.). The example I posted was
>"incorrect", since it defined a namespace in the <beans> tag. FYI, the
>XInclude spec provides DTD templates (and an XML schema) for XInclude
>usage:
>
><!ELEMENT xi:include (xi:fallback?)>
><!ATTLIST xi:include
>    xmlns:xi        CDATA       #FIXED   
>"http://www.w3.org/2001/XInclude"
>    href            CDATA       #IMPLIED
>    parse           (xml|text)  "xml"
>    xpointer        CDATA       #IMPLIED
>    encoding        CDATA       #IMPLIED
>    accept          CDATA       #IMPLIED
>    accept-language CDATA       #IMPLIED
>  
>
>
><!ELEMENT xi:fallback ANY>
><!ATTLIST xi:fallback
>    xmlns:xi   CDATA   #FIXED   "http://www.w3.org/2001/XInclude"
>  
>
>
>
>Regards,
>
>Timo
>  
>