[jdom-interest] Is JDOM dying?

[Malachi de AElfweald]

I disagree.  If you read in the XML, the ns attribute is only on
the root element. JDOM interprets that as it being on all children node.
If you try to programmatically put the XML together as it is seen
in textual format (only on the root element), JDOM adds it correctly,
then follows it with the ns="" which specifically breaks the inheritance.
If JDOM didn't add the ns="", then you could create JDOM just like you
see it in the XML file, by adding the ns attribute wherever you see it
in the XML file.

Malachi

On Fri, 14 Mar 2003 11:31:26 -0500 (EST), 
<Vadim.Strizhevsky at morganstanley.com> wrote:

>
> I think the problem with this aproach is that if you write out this
> document, and then read it back into JDOM, you'll get back a completely
> different looking structure. Because on input it would never have the
> INHERIT namespace tag. That I think is really problematic and something 
> to
> be avoided.
>
> In my opinion, the JDOM tree should not significantly change (whitespace
> excluded) if it was written out to a file and then back in. Otherwise you
> setting yourself up for all sorts of complications, and possibility of
> having code that correctly deals with one of these 2 trees, but not the
> other.
>
> I understand perfectly where this view comes from, but unfortunately it
> incorrectly reflects the reality (albeit quite confusing) of real
> specification of namespaces. I have to agree with Elliotte on this, I
> don't think there's a way to support this model without breaking the
> simplicity, and worst of all correctness of JDOM namespace behavior.
>
> Regards,
> -Vadim
>
> On 14 Mar 2003, Stephan Trebels wrote:
>
>> Here I am as advocatus diaboli even though I'm nearly sure I'd never use
>> it myself ;-/  But alas, this is a technical discussion not a religious
>> war - I hope.
>>
>>
>> disclaimer:
>> I'm sure, that normally it makes more sense to use an explicit
>> namespace in all Elements.  This is definitely true for all my work
>> areas where mutable Elements would be a nightmare.  This is not in
>> question.
>>
>>
>> But we have to face, that some people want to use Elements differently.
>> So I'd ask whether it is possible to make everyone happy without
>> sacrificing anything essential.
>>
>> In my compromise not a single line of code using JDOM anyone had have
>> written would be invalidated or behave any different.  The namespace set
>> by new Element(String) should not be changed - that should definitely be
>> rejected.
>>
>> The only added feature would be, that you CAN use a special Namespace
>> constant for different _output_ behaviour.  The only code changes would
>> have to be in the outputters.
>>
>>
>> So I ask you: Why/How would this make the API any uglier?  The API isn't
>> changed a bit.  The only way to get the changed behaviour would be to
>> use a static constant in the Namespace class, which can be documented
>> "for special applications, only". It shouldn't even be documented in a
>> user's guide (this would be something for a special addendum in the
>> reference).
>>
>>
>> My personal opinion about an API is, that it should be easy to use and
>> easy to learn, agreed.  Not all tasks need to be available in the
>> entry-level API, but ultimately all possible tasks should be made as
>> easy as possible.
>>
>> Stephan
>>
>> On Fri, 2003-03-14 at 13:46, Elliotte Rusty Harold wrote:
>> > At 8:56 AM +0100 3/14/03, Stephan Trebels wrote:
>> > >Would it be a workable compromise  to have a Namespace.INHERIT for an
>> > >Element as a possible namespace argument?
>> >
>> > I wouldn't accept such a compromise. It's ugly. Right now the JDOM
>> > namespace story is clean and consistent. This proposal says it
>> > changes depending on whether or not you set Namespace.INHERIT. Too
>> > many options just create a baroque API that's hard to learn, hard to
>> > teach, and hard to use. Generally when faced with two possible ways
>> > of accomplishing something, it's better to pick one than to pick both.
>> --
>> Stephan Trebels <stephan at ncube.de>   Consultant
>> company: nCUBE Deutschland GmbH, Hanauer Str. 56, 80992 Munich, Germany
>> phone: cell:+49 172 8433111  office:+49 89 1498930  fax:+49 89 14989350
>>
>>
>> _______________________________________________
>> To control your jdom-interest membership:
>> http://lists.denveronline.net/mailman/options/jdom- 
>> interest/youraddr at yourhost.com
>>
>>
>
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom- 
> interest/youraddr at yourhost.com
>
>



--