[Swift-devel] documenting sites.xml

Mihael Hategan hategan at mcs.anl.gov
Mon Sep 3 17:19:58 CDT 2007


Right. The karajan namespaces are more like java namespaces. But I'm not
sure I agree with the last part of what you say. Ambiguities cause
errors (as in Java).

Which means that you can't remap namespaces where you use them. There
are a few possibilities:

1. We document the way it works and forget the schema (most likely
finding meaning in an XML schema is not for the faint of heart).
2. We parse and verify the XML using a validating parser and generate
the relevant objects from that (this is the correct, but difficult path)
3. Karajan is adapted to do namespace remapping and we combine this with
a validator.

Mihael

On Mon, 2007-09-03 at 19:50 +0000, Ben Clifford wrote:
> 
> On Mon, 3 Sep 2007, Mihael Hategan wrote:
> 
> > > At present, sites.xml is a karajan code fragment document rather than an 
> > > XSD-compliant document (which manifests itself primarily in the handling 
> > > of namespaces). If it was an XSD-compliant file, then I'd use an XSD -> 
> > > documentation tool and put the descriptions in there.
> > 
> > What exactly is the difference?
> 
> karajan namespace handling appears to work quite differently from XSD 
> (traditional XML namespace handling).
> 
> in XSD, a sites file beginning:
> 
> <config xmlns="http://www.griphyn.org/chimera/GVDS-PoolConfig">
> 
> would be the same as
> 
> <s:config xmlns:s="http://www.griphyn.org/chimera/GVDS-PoolConfig">
> 
> and would not be the same as
> 
> <config>
> 
> (with s:prefix put on all the elements)
> 
> But in the Karajan implementation:
> 
> Execution failed:
>         's:pool' is not defined.
> 
> 
> Less relevantly in this particular situation, the defaulting works 
> differently too - defining an element in a different namespace can cause a 
> non-labelled element to mean something different in karajan, which doesn't 
> happen in XML Namespaces.
> 




More information about the Swift-devel mailing list