[jdom-interest] Is JDOM dying?

Fri Mar 14 08:55:50 PST 2003

Let me try again.

You have tree A that has INHERIT tags. You output it and read back in. You
now have tree B that doesn't have INHERIT tags. Semantically the 2 trees
are identical. However it would be hard/impossible to write code that
could treat the 2 trees the same. Imagine having to pass you tree to some
3rd party code that you have no control over. Do you expect them to
correctly deal with both situations? If not, then you broke the API
compatibility/stability.

Outputters are not the only things that look/examine/iterate over the
tree. And many other things you don't have control over. I don't see a way
to make the new model such that the tree A and tree B would  get
intepreted correctly and identically by the same code. More so, by the
code that exists today with current API.

Anyway, it should be fairly simple to write "inherit" functions that given
a parent and a child copies the parent's namespace to the child. You can
use these functions on construction, thus achieving basically what you
want.

-Vadim

On 14 Mar 2003, Stephan Trebels wrote:

> 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
>
>
>