[jdom-interest] Is JDOM dying?
stephan at ncube.de
Fri Mar 14 08:42:44 PST 2003
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
> 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.
> 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://email@example.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
More information about the jdom-interest