xom-interest AT lists.ibiblio.org
Subject: XOM API for Processing XML with Java
List archive
- From: Steve Loughran <steve.loughran AT gmail.com>
- Cc: xom-interest <xom-interest AT lists.ibiblio.org>
- Subject: Re: [XOM-interest] Scope of namespaces
- Date: Mon, 6 Feb 2006 10:15:51 +0000
On 2/5/06, peter murray-rust <pm286 AT cam.ac.uk> wrote:
> At 18:25 05/02/2006, Elliotte Harold wrote:
> >XOM's about as consistent on this as it's possible to be given the
> >general mess that is namespaces.
>
> I agree that namespaces are one of the worst specs to come out of the
> process. They were done in a great rush and generated much friction.
> The use of "http://..." as a name rather than an address is probably
> one of the worst ever decisions.
>
> > Given any element if you ask for the URI mapped to a given prefix,
> > then it will return the URI as specified by Namespaces in XML.
>
> Agreed. But if I want to ask for the namespaceURIs in scope, rather
> than the prefixes then I don't seem to be able to get them all:
This was a topic that was dicussed last week. Let's just say there are
some of us who do want to be able to get a list of all namespaces in
scope without having to walk up the tree, a process which IMO is best
described as "aggressively suboptimal" :)
However, for your problem, Xom should work.
String s = "<a xmlns:ns='http://foo'><b foo='ns:bar'/></a>";
If you get the value of attribute foo as a string and split it into
namespace and local by finding indexOf(':'), then you can ask element
b for the namespace matching prefix "ns".
LGPL code to do this from
http://cvs.sourceforge.net/viewcvs.py/smartfrog/core/components/xml/src/org/smartfrog/services/xml/java5/NamespaceUtils.java?view=markup
/**
* map from, say tns:something to 'tns'
*
* @param string
* @return null for no namespace
*/
public static String extractNamespacePrefix(String string) {
int offset = string.indexOf(':');
if (offset >= 0) {
return string.substring(0, offset);
} else {
return null;
}
}
/**
* map from, say tns:something to 'something'
*
* @param string
* @return everything following the : or the whole string if one is not
* there
*/
public static String extractLocalname(String string) {
int offset = string.indexOf(':');
if (offset >= 0) {
return string.substring(offset + 1);
} else {
return string;
}
}
Which is then used like this
Attribute extendsAttr = getExtendsAttribute();
if (extendsAttr != null) {
String rawextension = extendsAttr.getValue();
//now split that into namespace
String prefix =
NamespaceUtils.extractNamespacePrefix(rawextension);
String local = NamespaceUtils.extractLocalname(rawextension);
String namespace = null;
if (prefix != null) {
namespace = getNamespaceURI(prefix);
if (namespace == null) {
throw new CdlXmlParsingException(
ErrorMessages.ERROR_UNKNOWN_NAMESPACE + prefix);
}
}
setExtendsName(NamespaceUtils.makeQName(namespace, local,
prefix));
}
Where you do get into trouble is if you detach Element(b) from its
parent, Element (a). While Xom is clever enough to pull down all
namespace declarations of nodes and attributes (unlike, say, Dom), it
doesnt know that a string represents an XSD QName, so wont copy the
relevant declarations.
For this and other I am now strongly against using Qnames in
documents. I dont recall that being mentioned in ERH's Effective XML,
but I have found that they are more trouble than they are worth,
because
-You have new failure modes: qname without ns declaration above.
-You need to know where the qname was declared to be able to evaluate it.
-You can define the structure of the datatype element using a language
other than XSD
A design that used an element for, say typing is resolvable in its own
context , arguably more readable (yes, it's more verbose, but you dont
need to remember xmlns declarations), and a lot easier to work with
with tools such as XSL and XPath:
<b>
<types:datatype ns="http://ex.org" local="example" />
value
</b>
With this you could get a path of all nodes with a datatype in the
ex.org namespace. Try doing that with a layout like
<b types:datataype="ex:example" />
-Steve
-
Re: [XOM-interest] Scope of namespaces
, (continued)
-
Re: [XOM-interest] Scope of namespaces,
Elliotte Harold, 02/05/2006
-
Re: [XOM-interest] Scope of namespaces,
peter murray-rust, 02/05/2006
- Re: [XOM-interest] Scope of namespaces, Wolfgang Hoschek, 02/05/2006
-
Re: [XOM-interest] Scope of namespaces,
Elliotte Harold, 02/05/2006
- Re: [XOM-interest] Scope of namespaces, Michael Kay, 02/06/2006
-
Re: [XOM-interest] Scope of namespaces,
Elliotte Harold, 02/05/2006
-
Re: [XOM-interest] Scope of namespaces,
Michael Kay, 02/06/2006
- Re: [XOM-interest] Scope of namespaces, Elliotte Harold, 02/06/2006
- Re: [XOM-interest] Scope of namespaces, Elliotte Harold, 02/06/2006
- Re: [XOM-interest] Scope of namespaces, Steve Loughran, 02/06/2006
-
Re: [XOM-interest] Scope of namespaces,
Michael Kay, 02/06/2006
-
Re: [XOM-interest] Scope of namespaces,
Steve Loughran, 02/06/2006
- Re: [XOM-interest] Scope of namespaces, Elliotte Harold, 02/06/2006
- Re: [XOM-interest] Scope of namespaces, Elliotte Harold, 02/06/2006
-
Re: [XOM-interest] Scope of namespaces,
peter murray-rust, 02/05/2006
-
Re: [XOM-interest] Scope of namespaces,
Elliotte Harold, 02/06/2006
-
Re: [XOM-interest] Scope of namespaces,
peter murray-rust, 02/06/2006
-
Re: [XOM-interest] Scope of namespaces,
Steve Loughran, 02/06/2006
- Re: [XOM-interest] Scope of namespaces, Ed Davies, 02/06/2006
-
[XOM-interest] uuid generation (was Re: Scope of namespaces),
Tatu Saloranta, 02/06/2006
-
Re: [XOM-interest] uuid generation (was Re: Scope of namespaces),
Steve Loughran, 02/07/2006
- Re: [XOM-interest] uuid generation (OT), Tatu Saloranta, 02/07/2006
- Re: [XOM-interest] uuid generation (was Re: Scope of namespaces), Nils Kilden-Pedersen, 02/07/2006
-
Re: [XOM-interest] uuid generation (was Re: Scope of namespaces),
Steve Loughran, 02/07/2006
-
Re: [XOM-interest] Scope of namespaces,
Steve Loughran, 02/06/2006
-
Re: [XOM-interest] Scope of namespaces,
peter murray-rust, 02/06/2006
-
Re: [XOM-interest] Scope of namespaces,
Elliotte Harold, 02/05/2006
Archive powered by MHonArc 2.6.24.