[jdom-interest] Is JDOM dying?

[Stephan Trebels]

WHy is this problematic?  Currently JDOM represents the real structure
of XML, which happens to be my preferred one.  This would only be a
convenience method for people to BUILD a JDOM tree.  I'd never go as far
as allowing a parsing to build a JDOM tree with INHERIT Namespaces.

On Fri, 2003-03-14 at 17:31, 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@yourhost.com
> >
> >
-- 
        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