[jdom-interest] Is JDOM dying?

[Vadim.Strizhevsky at morganstanley.com]

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@yourhost.com
>
>