[jdom-interest] Namespace issues, et al.
Malachi de AElfweald
malachi at tremerechantry.com
Mon Feb 24 07:36:36 PST 2003
>> The semantics of an Element should not be contingent upon
>> it's surrounding context. This is a -feature-not a -bug-.
But, it is. Let's take a simple example.
Let's say you create a wrapper for a URL that has a method
createAttribute().
That method can return new Attribute("href", url.toExternalForm())
regardless of the
scope it is contained within.
Now we have some of the examples listed earlier. That one method can be
used
inside an xhtml scope, inside a SOAP scope, etc.... The logic of that
attribute is local to the scope of the element in which it is added. In
this particular
example, the logic is based off what we are wrapping -- not what we are
adding it to.
Using your design, you would have to call
createAttribute(element.getNamespace()) every
single call -- even though what you want to show up in the actual textual
representation
should NEVER have "xmlns='anything'" in it.
If I am creating an entire SOAP document, the xmlns is only on the root
element. As such,
I would only expect (until this conversation -- thus the non-intuitive
comment) that I only
have to set it on that element since that is the only element I want it to
appear on. Or to
be more accurate, I was expecting that I could just setAttribute on the
root element, but alas
that was a Runtime exception.
I understand that you want to be able to call Element e = new
Element("Envelope", soapNs) -- and
that is fine -- nothing I suggest changes that. What I am suggesting is
that many people on the
list (if you search for "Namespace" you will see MANY comments about it)
expected to be able
to call Element e = new Element("Envelope") and put that element inside any
other element that
is in the soapNs....
The 'bug' is that you can not inherit namespace from the parent -- even
though the spec says you can
and the XMLOutputter will output a document that does, and SAXBuilder reads
a document that does....
anotherwords -- everything works on the assumption that you can inherit
whatever namespace you are in
based on the scope, as per the spec -- EXCEPT when creating them from
scratch. When creating them from
scratch, I can not create a <url href="http://someurl"/> element and tell
it to stay in the same namespace
defined in the scope of the parent element.... But this is only a 'bug'
when creating documents. It can
not be a 'feature' if it fails to work the same creating documents as it
does outputting documents and
reading documents. Inconsistency is a 'bug'.
Malachi
On Mon, 24 Feb 2003 01:24:37 -0500 (EST), bob mcwhirter <bob at werken.com>
wrote:
>
> It's not a matter of -changing-a namespace.
>
> Element e = new Element( "Envelope", soapNs );
>
> That definitively creates a soap envelope element regardless
> of the context it ends up being attached. I don't have to
> worry about making sure it's within something that sets a namespace one
> way or the other.
>
> Element e = new Element( "Envelope" );
>
> So, using -your-idea:
>
> ...If I glue it into a SOAP document in the right place,
> it might end up being a SOAP envelope. If I glue it in at
> a different place in different document it might become
> a paper-goods envelope. To me, that radically chages the
> semantics of the element. And the semantics of the element
> should be fixed/deterministic.
>
> If you want a SOAP envelope, then make a SOAP envelope.
> If you want a paper-goods envelope, then make a paper-goods
> envelope.
>
> The semantics of an Element should not be contingent upon
> it's surrounding context. This is a -feature-not a -bug-.
>
> -bob
>
>
> On Sun, 23 Feb 2003, Malachi de AElfweald wrote:
>
>> Yes, I understand that now.... but I still don't agree with it.
>> The reason is that doing it that way means that, if I want to say
>> "use the same Namespace", I have to pass a namespace to the constructor.
>> If I want to use a different one than the parent (ie: "" instead of
>> whatever
>> it actually is), then I DON'T pass it into the constructor. The logic
>> is
>> backwards.
>>
>> Ie:
>> CURRENT:
>> new Element(name) -> change namespace to ""
>> new Element(name, NS) -> change namespace to NS
>>
>> SHOULD BE:
>> new Element(name) -> don't change namespace at all
>> new Element(name, NS) -> change namespace to NS
>>
>> Don't get me wrong. I think JDOM is the best XML API I have ever used.
>> However, it is non-intuitive to say "Don't pass a Namespace in the
>> constructor
>> means CHANGE namespace"... It should be "Don't pass a Namespace in the
>> constructor
>> means DON'T CHANGE namespace"...
>>
>> Malachi
>>
>> On Sun, 23 Feb 2003 22:36:11 -0600, Bradley S. Huffman
>> <hip at a.cs.okstate.edu> wrote:
>>
>> > Malachi de AElfweald writes:
>> >
>> >> The issue was 2-fold. If I created them with the xmlns in the >>
>> constructor, I was
>> >> also setting the xsi:schemaLocation attribute on it again -- thus the
>> >> first problem.
>> >> The second part of it was that I assumed (since textually it is true)
>> >> that putting
>> >> a tag inside another (like tagA above) inherits the namespace of the
>> >> parent element.
>> >> This is true in XML, and is true in the textual representation -- but
>> >> JDOM changes the
>> >> textual representation to break it... Thus, it can not inherit >>
>> namespaces from the parent
>> >> because of the fact xmlns="" is being added without my consent. If
>> that >> one piece was not
>> >> added, then it would all inherit correctly.
>> >
>> > JDOM does not change anything. If you run you text through
>> SAXBuilder,
>> > JDOM will build a faithful representation of it with JDOM objects >
>> (Element,
>> > Document, DocType, EntityRef, Namespace, and such). It will not
>> change,
>> > add, or delete any information. The problem seems to be you are
>> creating
>> > new objects and adding them to the treewhcih was built from your
>> texual
>> > representation and it's not producing what you think it should.
>> >
>> > Let take a simple example, running the following text though
>> SAXBuilder
>> >
>> > <root xmlns="my.default.namespace">
>> > <child1/>
>> > <child2/>
>> > </root>
>> >
>> > Produces the same objects as the following JDOM code
>> >
>> > Namespace defaultNS = Namespace.get("my.default.namespace");
>> > Element root = new Element("root", defaultNS);
>> > Text text1 = new Text("\n ");
>> > Element child1 = new Element("child1", defaultNS);
>> > Text text2 = new Text("\n ");
>> > Element child2 = new Element("child2", defaultNS);
>> > Text text3 = new Text("\n");
>> >
>> > root.addContent(text1);
>> > root.addContent(child1);
>> > root.addContent(text2);
>> > root.addContent(child2);
>> > root.addContent(text3);
>> >
>> > Document document = new Document(root);
>> >
>> > Now if you do a
>> >
>> > Element child3 = new Element("child3");
>> >
>> > Which is just shorthand for
>> >
>> > Element child3 = new Element("child3", Namespace.NO_NAMESPACE);
>> >
>> > It produces a new Element object such that
>> >
>> > child3.getName() returns "child3"
>> > child3.getNamespacePrefix() returns ""
>> > child3.getNamespaceURI() returns ""
>> >
>> > Then adding it to root Element object above
>> >
>> > root.addContent(child3);
>> >
>> > Means
>> >
>> > child3.getName() still returns "child3"
>> > child3.getNamespacePrefix() still returns ""
>> > child3.getNamespaceURI() still returns "", not
>> "my.default.namespace"
>> >
>> > And running document through XMLOutputter (without setting newlines
>> > or indent) produces
>> >
>> > <root xmlns="my.default.namespace">
>> > <child1/>
>> > <child2/>
>> > <child3 xmlns=""/></root>
>> >
>> > If you really want the textual representation to be
>> >
>> > <root xmlns="my.default.namespace">
>> > <child1/>
>> > <child2/>
>> > <child3/></root>
>> >
>> > i.e child3 is in the "my.default.namespace" namespace, then it should
>> of
>> > been constructed as follows
>> >
>> > Element child3 = new Element("child3", defaultNS);
>> >
>> > Again JDOM does not change anything unless explicitly told to do so.
>> >
>> > Brad
>> >
>> >
>>
>>
>>
>> --
>> _______________________________________________
>> To control your jdom-interest membership:
>> http://lists.denveronline.net/mailman/options/jdom-
>> interest/youraddr at yourhost.com
>>
>
> --
> Bob McWhirter bob at werken.com
> The Werken Company http://werken.com/
>
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-
> interest/youraddr at yourhost.com
>
>
--
More information about the jdom-interest
mailing list