XOM API for Processing XML with Java

[Andrew Thompson <lordpixel AT mac.com>]

On Mar 6, 2005, at 5:28 PM, Elliotte Harold wrote:
> > this case  it would be OK to skip emitting the xml:base attribute.
>
> That would be nonconformant to the XInclude spec. At a minimum XOM has 
> to write out xml:base="fragment.xml", except in a few rare cases where 
> it's including a piece of a document into itself, or xml:base 
> attributes in the included document make it look that way.
>
>
> > If on the other hand I write:
> >     <xi:include href="someOtherDir/SomeOtherFragment.xml">
> > Then the 2 URIs don't match up to their last component  
> > ("file:///foo/bar/baz/"  != "file:///foo/bar/baz/someOtherDir") and 
> > you  need to add an xml:base to the included fragment. I think that 
> > would  work recursively for documents included in the fragment too?
>
> I'll add this to the TODO list. I may or may not get to this in 1.1.

Hey, thanks! Not sure what you mean though. It's non-conformant but 
you're going to make it an option anyway?
Or do you mean you'll detect this case and just strip it down to 
xml:base="fragment.xml"?

I guess that more or less solves my problem.
Actually, what would this mean if I didn't deploy fragment.xml to the 
web server?
If an element has xml:base="fragment.xml" what does it imply for 
relative URIs inside that element if "fragment.xml" does not exist in 
the deployment filesystem?

Conceptually to me it's much more useful for relative URIs to end up 
relative to the final resolved document that to mess around with 
xml:base trying to make them relative to the original document 
fragment, which may not even exist! What I mean is, if I merge 
index.xml and fragment.xml into index.html, then upload only index.html 
to my webserver, then why would I want URIs relative to fragment.xml or 
index.xml? To me merging these documents conceptually makes the 
relative URIs relative to the resulting document.

Which is not to say there isn't plenty of reason why other people with 
other applications wouldn't want the xml:base behaviour, but the spec 
should have supported both and they seemed to have missed that use case 
altogether...?
Thanks for the xmlns="" fix BTW. Obvious, once you see it!

AndyT (lordpixel - the cat who walks through walls)
A little bigger on the inside

        (see you later space cowboy ...)