Matt Benson wrote:
--- Steve Loughran <[EMAIL PROTECTED]> wrote:
Maybe. :) But really, I appreciate your input. I
have no problem admitting how clueless I am wrt xml in
general and ns in particular. :|
rule 1 of xml: nobody understands XML namespaces
rule 2: anybody who says they do. still doesnt.
so there are the following categories
-ignorant of xmlns
-vaguely aware, but doesnt understand
-think they understand, but doesnt really
-knows xmlns enough to know it doesnt make sense, and doesnt understand
if you meet someone who thinks they do understand it, ask them if, in
xml schema, the ##local namespace is in ##other, or not.
For the record, I know enough for them to scare me, that's it.
have had to deal with
exactly this kind of problem in the past, where we
really did have to
extract and maintain the xmlns list. And believe me,
Xom does not go out
of its way to make that easy
Can we mitigate any of this with usage guidelines?
Three ways to resolve a type, the first two of which
are easy:
- use a type in a globally defined ns
- use e.g antlib:org.foo/type
1.
> - use a type in a globally defined ns
kind of breaks some of the xmlns rules
2.
> - use e.g antlib:org.foo/type
this is somewhat similar to how XPath lets you insert new XMLNS
declarations. If you were do it, I'd prefer
{http://example.org}type as that is equivalent to how
javax.xml.QName.toString() works
3.
third option would require awareness of available
namespaces at the time of resolution, so if you
defined
<property name="resource" value="myns:type?blah" />
you'd have to say:
<echo output="${resource}"
xmlns:myns="antlib:org.myorg" />
or whatever... does that solve and/or accomplish
anything?
it would certainly work, but be unduly painful. Your task would need to
know which namespace declarations to put i for a resource, which then
becomes something you can't change.
Other options
-make a QName an official Ant type. When you set it, the XMLNS gets
expanded. This is a good idea anyway; too bad QNAme is only built in to
java5, though javax.xml.namespace is available as an add-on for older code.
you could create one in the qname task
<qname ns="http://org.example/"; local="local" > ==
{http://org.example/}local
<qname local="local" > == {}local
<qname ns="something" > == BuildException no local
<qname value="prefix:value" > == {lookup(prefix)}value ... xmlns:prefix
would have to be up the tree
Of course, this doesnt help you with the problem of defining resource
destinations in a string, or a properties file...
-Make an xmlns context something else that is a datatype
<namespaces id="here" /> //cache all defined xmlns in this element's
scope
<namespaces refid="here" /> //extract the namespaces and add them to the
parent node (i.e. the target)
<echo output="${resource}" />
Not sure whether I like that one.
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
