[jdom-interest] Is JDOM dying?

Fri Mar 14 23:19:38 PST 2003

To do that, wouldn't you have to create a new JDOM tree from scratch
based off the old one -- ie: JDOM doesn't allow you to change the Namespace
of an existing Element, correct?  The problem there is time-sensitive...
I already was told to rip out all references to SAXBuilder because it was
too slow (87 seconds as opposed to 4 for DOMParser+DOMBuilder).

Malachi

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

>
>
> If you _really_ want this, you can do this with current JDOM API.
> Introduce a dummy namespace:
>
> Namespace INHERIT = Namespace.getNamespace("INHERIT","INHERIT");
>
> Use it as you propose. Write a function that takes such a JDOM tree and
> converts to a "proper" JDOM tree. You would call this function before
> outputting the tree. It would fairly straight forward to write this
> function, it just needs to iterate over all elements and for
> INHERIT namespace, replace with the parent's namespace.
>
> -Vadim
>
> On Fri, 14 Mar 2003 Vadim.Strizhevsky at morganstanley.com wrote:
>
>>
>> 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 at 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
>> >
>> >
>> >
>>
>>
>> _______________________________________________
>> 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
>
>

-- 