From cameron.smith at entranet.co.uk  Fri Sep  1 02:51:18 2000
From: cameron.smith at entranet.co.uk (Cameron Smith)
Date: Fri Aug  6 17:04:45 2004
Subject: [jdom-interest] children as List
Message-ID: <03AC580B0983D311BD370050043724E901363BCC@TC-MAIL01>

I think its the right decision to present the children of an Element as a
List rather than having List-like behaviour in Element itself.

This is because:
1)  List is almost a 'basic type' now in java: so using it is 'second
nature', as opposed to NodeList in DOM.
2)  If we take the idea of 'pure objects' to the extreme then every class we
create which has a variable number of a certain type of object would need
its own 'list-style' interface.  Instead, whenever I see a '1-n'
relationship between parent and children I think of a 'List' or 'Iterator'
interface to provide access to it.

The main downside of this is the vulnerability of exposing the List to
mangling by user code.   However user code which wants to protect itself
(and in many cases will /want/ to be mangling the List) from this can use
the Collections.unmodifiableList() method.  

Another issue was ClassCastExceptions.  I think this is more an issue of
whether or not there should be a unified class hierarchy in JDom, so that
everything can be safely cast to 'Element', (like Node in DOM) than an issue
about where to put List behaviour.

	Cameron Smith, Software Developer
	Entranet Ltd
	 


From joerg at freiheit.com  Fri Sep  1 03:31:34 2000
From: joerg at freiheit.com (Joerg)
Date: Fri Aug  6 17:04:45 2004
Subject: [jdom-interest] Element.getDocument() ?
References: <Pine.LNX.3.96.1000831041911.7905u-100000@exeter.exeter.org> <39AE25F0.92D403C2@collab.net> <39AE758C.14F46FBE@lutris.com> <0008311739240U.00913@excalibur.peernet>
Message-ID: <39AF8586.5E7C8CC7@freiheit.com>

Ah, now I got the point. Jason already proposed there to replace isRootElement by
parentDocument, to set this only for the root Element and take it therefore as a flag
to mark the root Element. This was a little bit too fast for me.

I did not read it carefully enough :-) and I understood at this point to take
(parentElement == null) as an indicator for the root Element (maybe Brett had the
same misunderstanding).

Joerg


Trebor A. Rude wrote:

> On Thu, 31 Aug 2000, you wrote:
> >Jason Hunter wrote:
> >> bob wrote:
> >> > Probably just recursively getParent() until isRootElement(),
> >> > and hold a reference to the Document there.  Maybe.
> >>
> >> Sounds about right.  You could save space and some logic work by
> >> getting rid of the isRootElement boolean and just handling a
> >> parentDocument Element reference.  For example, you implement
> >> isRootElement() as:
> >>
> >> return (parentDocument != null);
> >
> >Actually, this doesn't work, as any Element created like so:
> >
> >Element nonRoot = new Element("foo");
> >
> >would think it is the root element.
> >
> >-Brett
>
>         Why would it think it's the root? If the Element is created that way its
> parent document should be set to null (what else could it be set to?), so
> != null would return false.
>
> --
> Trebor A. Rude
> trebor@bwn.net
> Registered Linux User #89308
> http://counter.li.org/
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com



--
<?xml version="1.0" standalone="no" encoding="ISO-8859-1"?>
<businesscard>
  <bookmarks>
    <bookmark> http://www.google.com </bookmark>
    <bookmark> http://www.gnu.org </bookmark>
    <bookmark> http://java.apache.org </bookmark>
    <bookmark> http://www.w3.org </bookmark>
    <bookmark> http://www-db.stanford.edu/lore </bookmark>
  </bookmarks>
  <sender>
    <firstname> J?rg </firstname>
    <name> Kirchhof </name>
    <title> Dipl.-Ing. </title>
    <email> joerg@freiheit.com </email>
    <phone> +49-40-890584-14 </phone>
  </sender>
  <company>
    <name> freiheit.com Technologieberatung GmbH </name>
    <address> Theodorstra?e 42-90 </address>
    <zip> 22761 </zip>
    <city> Hamburg </city>
    <country> Germany </country>
    <phone> +49-40-890584-0 </phone>
    <fax> +49-40-890584-20 </fax>
    <www> http://www.freiheit.com </www>
  </company>
</businesscard>



From mago at mail.internet.com.mx  Fri Sep  1 05:03:55 2000
From: mago at mail.internet.com.mx (Gerardo Horvilleur)
Date: Fri Aug  6 17:04:45 2004
Subject: [jdom-interest] Re: Fast or Safe?
References: <200008310604.AAA16501@dorothy.denveronline.net> <0008311810480V.00913@excalibur.peernet> <39AEF686.226AB02A@mail.internet.com.mx> <0008312231300W.00913@excalibur.peernet>
Message-ID: <39AF9B2B.EA796FF1@mail.internet.com.mx>

> >It would be something like: Element foo = factory.newElement("foo")
> >which seems reasonable enough to me. It is not too different from
> >what we have right now and it makes it possible to have multiple
> >implementations.
> 
>         It's quite reasonable, my only concern is that it probably breaks all
> existing code, which we may not want to do. Fortunately we're in the
> pre-1.0 stage, and it's easier to justify the large change. Brett? Jason?
> What do you think?
> 

I wonder what percentage of the programs using JDOM are only using it to parse
and extract information from an XML file by using a SAXBuilder or DOMBuilder, and
therefore do not have any line of code where they explicitly create an Element
(or Attribute, etc.). If SAXBuilder and DOMBuilder use a default factory unless told
otherwise, then none of those programs would be affected.
-- 

Gerardo Horvilleur
mago@mail.internet.com.mx

From elharo at metalab.unc.edu  Fri Sep  1 04:29:36 2000
From: elharo at metalab.unc.edu (Elliotte Rusty Harold)
Date: Fri Aug  6 17:04:45 2004
Subject: [jdom-interest] XMLOutputter documentation doesn't match the
 code.
In-Reply-To: <000901c0137b$baeeef20$8d01a8c0@horizonint.com>
References: <000901c0137b$baeeef20$8d01a8c0@horizonint.com>
Message-ID: <v04210100b5d543351156@[192.168.1.254]>

At 12:46 PM -0600 8/31/00, Brad Morgan wrote:
>The Javadoc documentation states that XMLOutputter() defaults to two space
>indent and new lines.  The code appears to implement no indent and no new
>lines.
>

Don't get too worked up about any inconsistencies you find in 
XMLOutputter just yet. There are still going to be major changes to 
the API and implementation of this class for 1.0 so there's not a lot 
to be gained by tweaking the existing code. Progress has stopped for 
the time being while we're arguing about how to implement the changes 
we all know are needed.

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
|                  The XML Bible (IDG Books, 1999)                   |
|              http://metalab.unc.edu/xml/books/bible/               |
|   http://www.amazon.com/exec/obidos/ISBN=0764532367/cafeaulaitA/   |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://metalab.unc.edu/javafaq/ |
|  Read Cafe con Leche for XML News: http://metalab.unc.edu/xml/     |
+----------------------------------+---------------------------------+

From elharo at metalab.unc.edu  Fri Sep  1 04:56:00 2000
From: elharo at metalab.unc.edu (Elliotte Rusty Harold)
Date: Fri Aug  6 17:04:45 2004
Subject: [jdom-interest] children as List
In-Reply-To: <03AC580B0983D311BD370050043724E901363BCC@TC-MAIL01>
References: <03AC580B0983D311BD370050043724E901363BCC@TC-MAIL01>
Message-ID: <v04210100b5d5490d376c@[192.168.1.254]>

At 10:51 AM +0100 9/1/00, Cameron Smith wrote:
>I think its the right decision to present the children of an Element as a
>List rather than having List-like behaviour in Element itself.
>
>This is because:
>1)  List is almost a 'basic type' now in java: so using it is 'second
>nature', as opposed to NodeList in DOM.

This is irrelevant. If we made Element a List we'd still be using all 
the familiar methods of java.util.List.  We're not proposing to 
eliminate the use of the List interface, just to make Element 
implement it. It would not be as unfamiliar as NodeList.

>2)  If we take the idea of 'pure objects' to the extreme then every class we
>create which has a variable number of a certain type of object would need
>its own 'list-style' interface.  Instead, whenever I see a '1-n'
>relationship between parent and children I think of a 'List' or 'Iterator'
>interface to provide access to it.
>

You could get an iterator on the children. And you could get a List 
of the children. It would just be a little easier to do so.

>The main downside of this is the vulnerability of exposing the List to
>mangling by user code.   However user code which wants to protect itself
>(and in many cases will /want/ to be mangling the List) from this can use
>the Collections.unmodifiableList() method.
>

The List is still exposed in either version.

>Another issue was ClassCastExceptions.  I think this is more an issue of
>whether or not there should be a unified class hierarchy in JDom, so that
>everything can be safely cast to 'Element', (like Node in DOM) than an issue
>about where to put List behaviour.
>

This can be fixed in either version.

None of these points argue to the question of whether Element should 
contain a List or implement a List. They are all equally applicable 
to both cases.

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
|                  The XML Bible (IDG Books, 1999)                   |
|              http://metalab.unc.edu/xml/books/bible/               |
|   http://www.amazon.com/exec/obidos/ISBN=0764532367/cafeaulaitA/   |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://metalab.unc.edu/javafaq/ |
|  Read Cafe con Leche for XML News: http://metalab.unc.edu/xml/     |
+----------------------------------+---------------------------------+

From elharo at metalab.unc.edu  Fri Sep  1 05:02:22 2000
From: elharo at metalab.unc.edu (Elliotte Rusty Harold)
Date: Fri Aug  6 17:04:45 2004
Subject: [jdom-interest] insertChild in Element
In-Reply-To: <39AE73C2.5E408087@lutris.com>
References: <HCEOJDJOJJLJAFCILPLLKEBMCAAA.chris.hamersley@xmlglobal.com>	
 <4.3.2.7.2.20000830090141.032ec6f0@mail.ic.net>
 <4.3.2.7.2.20000831083954.032dc1e0@mail.ic.net>
 <39AE73C2.5E408087@lutris.com>
Message-ID: <v04210102b5d54a808ec3@[192.168.1.254]>

At 10:03 AM -0500 8/31/00, Brett McLaughlin wrote:

>OK, I think we can pretty much resolve this. I've seen two folks that
>want this functionality, you and Trevor Rude. And I know that Jason and
>I are in consensus that it really isn't needed. There is a real danger
>of API bloat in doing what you propose. I've also yet to see any
>use-case (referring to "good programming principles" just doesn't do it)
>for the need for this. Finally, every Java 2 developer is familiar with
>Collections, or should be. So I think it's safe to say that while this
>was good discussion, I'm even more convinced that getting the List and
>operating on it is sufficient. It would create at least 10-15 new
>methods that are exact copies of List methods, with new names!!, and not
>add any new functionality.
>

No, that's not what it would do. This discussion seems to have veered 
off track. The names would not be new names. The names would be the 
exact same names used currently in the List interface because the 
Element class would implement the List interface.

The fact is getting a List by invoking a method and then operating on 
it just isn't obvious to most people. It's not hard but it is 
confusing. We've seem that again and again on this mailing list. It 
would be more intuitive if all the methods needed were sitting right 
there in the Element class.

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
|                  The XML Bible (IDG Books, 1999)                   |
|              http://metalab.unc.edu/xml/books/bible/               |
|   http://www.amazon.com/exec/obidos/ISBN=0764532367/cafeaulaitA/   |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://metalab.unc.edu/javafaq/ |
|  Read Cafe con Leche for XML News: http://metalab.unc.edu/xml/     |
+----------------------------------+---------------------------------+

From philip.nelson at omniresources.com  Fri Sep  1 05:22:35 2000
From: philip.nelson at omniresources.com (philip.nelson@omniresources.com)
Date: Fri Aug  6 17:04:45 2004
Subject: [jdom-interest] XMLOutputter documentation doesn't match the 
	code.
Message-ID: <DF5018B3C986D11196FF0060089A903C2BFE65@gbdev.omniresource.com>

> The Javadoc documentation states that XMLOutputter() defaults 
> to two space
> indent and new lines.  The code appears to implement no 
> indent and no new
> lines.
> 

This is already fixed in the CVS version ;)

From elharo at metalab.unc.edu  Fri Sep  1 05:31:28 2000
From: elharo at metalab.unc.edu (Elliotte Rusty Harold)
Date: Fri Aug  6 17:04:45 2004
Subject: [jdom-interest] API instability?
In-Reply-To: <39AE8248.228AE913@collab.net>
References: 
 <51C6625F6F63D211853B0008C74C1A1EFA779E@corp-exchg-001.synchrony.net>
 <39AE74C9.6D2C4954@lutris.com> <39AE8248.228AE913@collab.net>
Message-ID: <v04210103b5d55191379b@[192.168.1.254]>

At 6:05 PM +0200 8/31/00, Jason Hunter wrote:

>I'm not sure it's the right thing to go this way but let's look it
>over.  I don't see what bugs you'd have when moving elements between
>docs.  The simple idea is that if you have
>
><foo:parent>
>  <foo:child/>
></foo:parent>
>
>When you say parent.getChild("child") it's kinda natural for the
>unspecified namespace of "child" to be the same as the parent, not the
>no-namespace.  It's a simple way of thinking: ask Bob Jones about his
>kid Billy and he naturally refers to the Billy in the Jones namespace.
>:-)
>

Bugs or no bugs, this just doesn't seem obvious to me. I'd rather 
explicitly specify my namespaces. I think this is going to cause big, 
unexpected problems for programmers when they encounter documents 
where the children don't have the same namespaces as the parent.

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
|                  The XML Bible (IDG Books, 1999)                   |
|              http://metalab.unc.edu/xml/books/bible/               |
|   http://www.amazon.com/exec/obidos/ISBN=0764532367/cafeaulaitA/   |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://metalab.unc.edu/javafaq/ |
|  Read Cafe con Leche for XML News: http://metalab.unc.edu/xml/     |
+----------------------------------+---------------------------------+

From philip.nelson at omniresources.com  Fri Sep  1 05:41:27 2000
From: philip.nelson at omniresources.com (philip.nelson@omniresources.com)
Date: Fri Aug  6 17:04:46 2004
Subject: [jdom-interest] accessing Element.getChildren() elements with
	 a ListIterator
Message-ID: <DF5018B3C986D11196FF0060089A903C2BFE66@gbdev.omniresource.com>

> Could someone please explain why the ListIterator approach 
> doesn't work;

You don't say what doesn't work ;)  I have used the ListIterator without any
problems but not in recursive code.

From cameron.smith at entranet.co.uk  Fri Sep  1 06:03:04 2000
From: cameron.smith at entranet.co.uk (Cameron Smith)
Date: Fri Aug  6 17:04:46 2004
Subject: [jdom-interest] children as List
Message-ID: <03AC580B0983D311BD370050043724E901363BD0@TC-MAIL01>

in reply to Elliote:

> -----Original Message-----
> From: Elliotte Rusty Harold [mailto:elharo@metalab.unc.edu]
> Sent: Friday, September 01, 2000 12:56 PM
> To: Cameron Smith; 'jdom-interest@jdom.org'
> Subject: Re: [jdom-interest] children as List
> 
> 
> At 10:51 AM +0100 9/1/00, Cameron Smith wrote:
> >I think its the right decision to present the children of an 
> Element as a
> >List rather than having List-like behaviour in Element itself.
> >
> >This is because:
> >1)  List is almost a 'basic type' now in java: so using it is 'second
> >nature', as opposed to NodeList in DOM.
> 
> This is irrelevant. If we made Element a List we'd still be using all 
> the familiar methods of java.util.List.  We're not proposing to 
> eliminate the use of the List interface, just to make Element 
> implement it. It would not be as unfamiliar as NodeList.
Good point - however, if we make Element a List and throw
UnsupportedOperationExceptions for the ops we don't want to provide, and we
treat a lot of ops this way, we are in fact 'unfamiliarising' users as what
is apparently a List is really not the real McCoy.  On the other hand, this
approach does give us control over what people do to the list - but if we
take it too far it would in fact be clearer to use a 'proprietary' type like
NodeList which simply doesn't have the missing ops.  Either way, though,
whatever List-like interface you end up providing, you could have Element
implement it directly or return it, that's true.


> >2)  If we take the idea of 'pure objects' to the extreme 
> then every class we
> >create which has a variable number of a certain type of 
> object would need
> >its own 'list-style' interface.  Instead, whenever I see a '1-n'
> >relationship between parent and children I think of a 'List' 
> or 'Iterator'
> >interface to provide access to it.
> >
> 
> You could get an iterator on the children. And you could get a List 
> of the children. It would just be a little easier to do so.
Sorry, I wasn't very clear here: what I mean is, do we need to make things
easier to the extent of making an Element, which semantically is more than
just a list, implement List, when we could just return a List?  If a
structure has a collection of children should it always directly implement a
collection-like interface?

> >The main downside of this is the vulnerability of exposing 
> the List to
> >mangling by user code.   However user code which wants to 
> protect itself
> >(and in many cases will /want/ to be mangling the List) from 
> this can use
> >the Collections.unmodifiableList() method.
> >
> 
> The List is still exposed in either version.
Given the target audience of JDom, is that a risk?

> >Another issue was ClassCastExceptions.  I think this is more 
> an issue of
> >whether or not there should be a unified class hierarchy in 
> JDom, so that
> >everything can be safely cast to 'Element', (like Node in 
> DOM) than an issue
> >about where to put List behaviour.
> >
> This can be fixed in either version.
Agreed - so it doesn't affect the argument either way.

cameron smith 

From dsmiley at mitre.org  Fri Sep  1 06:43:36 2000
From: dsmiley at mitre.org (David W. Smiley)
Date: Fri Aug  6 17:04:46 2004
Subject: [jdom-interest] How to "crash" JDOM, part 1
References: <200008312256.QAA15867@dorothy.denveronline.net>
Message-ID: <39AFB288.A0B4377E@mitre.org>

> The right solution is for JDOM somehow to support both worlds.  Because
> if it doesn't, then someone (could be me) has an incentive to fork and
> write a version without all the checks that runs faster.  How to support
> both "sanity checking" and "non-sanity checking" version is the real
> trick.

--hence the need for the builder design pattern.  But it looks like it's
becoming too late for such a major change since beta5 is nearing.  The
change would mostly reflect implementation of existing classes and the
input classes.

-- David Smiley


From trebor at bwn.net  Fri Sep  1 06:46:55 2000
From: trebor at bwn.net (Trebor A. Rude)
Date: Fri Aug  6 17:04:46 2004
Subject: [jdom-interest] children as List
In-Reply-To: <03AC580B0983D311BD370050043724E901363BCC@TC-MAIL01>
References: <03AC580B0983D311BD370050043724E901363BCC@TC-MAIL01>
Message-ID: <00090107465500.00871@excalibur.peernet>

On Fri, 01 Sep 2000, Cameron Smith wrote:

>Another issue was ClassCastExceptions.  I think this is more an issue of
>whether or not there should be a unified class hierarchy in JDom, so that
>everything can be safely cast to 'Element', (like Node in DOM) than an
> issue about where to put List behaviour.

	How about creating a tagging interface (like Serializable) instead of 
unifying the class hierarchy? This way, anything that wants to operate on 
just JDOM nodes (and not just a specific class of JDOM nodes) can be sure 
it's got one by testing for the tag. And it provides a useful place to put 
whatever functionality may be common (such as getParent()) if we do decide 
to unify the hierarchy.

-- 
Trebor A. Rude
trebor@bwn.net
Registered Linux User #89308
http://counter.li.org/

From elharo at metalab.unc.edu  Fri Sep  1 06:56:27 2000
From: elharo at metalab.unc.edu (Elliotte Rusty Harold)
Date: Fri Aug  6 17:04:46 2004
Subject: [jdom-interest] children as List
In-Reply-To: <03AC580B0983D311BD370050043724E901363BD0@TC-MAIL01>
References: <03AC580B0983D311BD370050043724E901363BD0@TC-MAIL01>
Message-ID: <v04210100b5d5641390e7@[192.168.1.254]>

At 2:03 PM +0100 9/1/00, Cameron Smith wrote:
>in reply to Elliote:

>> This is irrelevant. If we made Element a List we'd still be using all
>> the familiar methods of java.util.List.  We're not proposing to
>> eliminate the use of the List interface, just to make Element
>> implement it. It would not be as unfamiliar as NodeList.
>Good point - however, if we make Element a List and throw
>UnsupportedOperationExceptions for the ops we don't want to provide, and we
>treat a lot of ops this way, we are in fact 'unfamiliarising' users as what
>is apparently a List is really not the real McCoy.  On the other hand, this
>approach does give us control over what people do to the list - but if we
>take it too far it would in fact be clearer to use a 'proprietary' type like
>NodeList which simply doesn't have the missing ops.  Either way, though,
>whatever List-like interface you end up providing, you could have Element
>implement it directly or return it, that's true.
>

We wouldn't throw any UnsupportedOperationExceptions! or at least any 
we don't throw now (I don't think we're throwing any now, but I 
haven't checked the source.) Everything we provide now would still be 
provided. The method signatures would be the same. The behavior would 
be the same. The exceptions would be the same. The only question is 
where we put the interface, in Element itself or in a different class.

>Sorry, I wasn't very clear here: what I mean is, do we need to make things
>easier to the extent of making an Element, which semantically is more than
>just a list, implement List, when we could just return a List?  If a
>structure has a collection of children should it always directly implement a
>collection-like interface?
>

That Element is more than a List doesn't mean that it isn't a List. 
List is an interface, not a class. It is intended that List will be 
implemented by classes that do a whole lot more than merely manage 
lists. The more I think about it the more I'm convinced, though, that 
logically Element IS A List; that is, it is not simply a relationship 
of HAS A List. In common discussion we talk about the Element's 
children, not the children of the Element's list. Nothing in the XML 
specs talks about a list that's somehow associated with the Element. 
That's a JDOM invention. What is the definition of List if not an 
ordered set of items, the items  normally being called the children 
of the list? Element contains children in a particular order. Things 
that have ordered children are lists. Therefore Element is a list. 
QED.


+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
|                  The XML Bible (IDG Books, 1999)                   |
|              http://metalab.unc.edu/xml/books/bible/               |
|   http://www.amazon.com/exec/obidos/ISBN=0764532367/cafeaulaitA/   |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://metalab.unc.edu/javafaq/ |
|  Read Cafe con Leche for XML News: http://metalab.unc.edu/xml/     |
+----------------------------------+---------------------------------+

From brett.mclaughlin at lutris.com  Fri Sep  1 07:46:53 2000
From: brett.mclaughlin at lutris.com (Brett McLaughlin)
Date: Fri Aug  6 17:04:46 2004
Subject: [jdom-interest] Re: Fast or Safe?
References: <200008310604.AAA16501@dorothy.denveronline.net> <0008311810480V.00913@excalibur.peernet> <39AEF686.226AB02A@mail.internet.com.mx> <0008312231300W.00913@excalibur.peernet>
Message-ID: <39AFC15D.5828AB7@lutris.com>


"Trebor A. Rude" wrote:
> 
> On Thu, 31 Aug 2000, Gerardo Horvilleur wrote:
> >"Trebor A. Rude" wrote:
> >>         Hmm, if we do that, we could create a sigleton factory class
> >> to return you the proper implementation of the interface based on some
> >> settings it's got stored. At the very least, the programmer would be
> >> forced to manually create objects of the correct implementation. Of
> >> course, either way would probably break every existing JDOM program out
> >> there, as the "Element foo = new Element("foo");" idiom would break.
> >> Even though we could, with the claim "the API is pre-1.0", I'm not sure
> >> many people would be very happy if we did that. Design wise, it sounds
> >> fine though.
> >
> >It would be something like: Element foo = factory.newElement("foo")
> >which seems reasonable enough to me. It is not too different from
> >what we have right now and it makes it possible to have multiple
> >implementations.
> 
>         It's quite reasonable, my only concern is that it probably breaks all
> existing code, which we may not want to do. Fortunately we're in the
> pre-1.0 stage, and it's easier to justify the large change. Brett? Jason?
> What do you think?

I continue to be against factories. It's unnecessary, I'm still
convinced. Because it is the first option apparant to perform this task
does not mean it is the best. It also makes implementation very messy,
breaks all existing code in a /fundamental way/, causes many of the JDOM
newbies to be totally lost, and AFAIK still doesn't add significant
functionality.

We went through this once every month or so, so I'd refer you to the
archives for more details... I'm so far from being convinced this is
even a good idea, though...

-Brett

> 
> --
> Trebor A. Rude
> trebor@bwn.net
> Registered Linux User #89308
> http://counter.li.org/
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org

From brett.mclaughlin at lutris.com  Fri Sep  1 10:52:02 2000
From: brett.mclaughlin at lutris.com (Brett McLaughlin)
Date: Fri Aug  6 17:04:46 2004
Subject: [jdom-interest] Changes to SAXBuilder and XMLOutputter
Message-ID: <39AFECC2.512DB3B@lutris.com>

All-

  I made lots of changes today to SAXBuilder and XMLOutputter.

SAXBuilder
---------

* Updated some Javadoc stuff
* Added setDTDHandler
 - allows custom DTDHandler to be supplied
* Added setValidation
 - allows validation to be turned on and off; this is useful when using
   the same SAXBuilder class over and over on different documents, when
   only some should be validated.

XMLOutputter
------------

* Added setIndent(String)
 - sets indention size (default is "")
* Added setLineSeparator(String)
 - sets line separator (default is "\r\n")
* Added setIndentation
* Added setSuppressDeclaration(String)
 - sets whether to show the XML declaration (default is show it)
 - Helps people using XML-RPC and SOAP
* Added setOmitEncoding(boolean)
 - Allows document encoding to be omitted (default is show it)
 - Helps WAP clients and wireless clients
* Added setIndentSize(int)
 - Sets number of spaces to use for indent (default is none)
* Added setIndenting(boolean)
 - whether or not to use indentation at all

I know we had talked about whether or not these should be a separate
object, but nobody ever said anything compelling either way, so I just
wanted to get things going. I still don't see a real need for
HTMLOutputter or anything else, at least not yet, so we needed to get
moving.

In general, check out TODO.txt to see what still needs to be done.

I'm going to try and get some of these patches in later today.

-Brett

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org

From Patrick.Dowler at nrc.ca  Fri Sep  1 10:24:43 2000
From: Patrick.Dowler at nrc.ca (Patrick Dowler)
Date: Fri Aug  6 17:04:46 2004
Subject: [jdom-interest] children as List
In-Reply-To: <03AC580B0983D311BD370050043724E901363BD0@TC-MAIL01>
References: <03AC580B0983D311BD370050043724E901363BD0@TC-MAIL01>
Message-ID: <0009011058180E.04558@kitasoo.hia.nrc.ca>

On Fri, 01 Sep 2000, Cameron Smith wrote:
> > This is irrelevant. If we made Element a List we'd still be using all 
> > the familiar methods of java.util.List.  We're not proposing to 
> > eliminate the use of the List interface, just to make Element 
> > implement it. It would not be as unfamiliar as NodeList.
>
> Good point - however, if we make Element a List and throw
> UnsupportedOperationExceptions for the ops we don't want to provide, and we
> treat a lot of ops this way, we are in fact 'unfamiliarising' users as what
> is apparently a List is really not the real McCoy.  On the other hand, this
> approach does give us control over what people do to the list - but if we
> take it too far it would in fact be clearer to use a 'proprietary' type like
> NodeList which simply doesn't have the missing ops.  Either way, though,
> whatever List-like interface you end up providing, you could have Element
> implement it directly or return it, that's true.

There is one big problem with "Element implements List" when it comes to
type-safety. Element would have "add(Object)" which allows anything. We
would have to throw a ClassCastException if the wrong type is supplied.
The compiler will not catch this type of error. 

If we have PartialList do type-checking, we are essentially in the same boat
(runtime exceptions). Manually doing the type check is costly (casting or
instanceof).

To gain compile-time type safety, one has to not use the List interface or
expose the underlying List via getChildren(). It doesn't sound like this is much
of a priority to most of the developers, but it does pay off in the long run.
What it does mean is that Element would have its own API and would have
to provide all the required functionality. This could be a type-safe version
of the List API (the docs just say "if you know List, you know Element")
by having add(Element), add(Comment), etc and doing the right thing inside.
I do not think actually implementing the List interface is the way to go, but
I do think Element should directly provide the features in order to ensure type
safety  - at compile time!

I can already hear people saying "type safety? we don't need no stinking
type safety!" If we do not go this way, in the end we end up with a
lot of error checking  code inside the core classes.

As for the "is a List" vs. "has a List" neither is really correct. Element has
a list (children) and a map (attributes). Do we also expose the attribute
map?

BTW, thsi is certainly a hot discussion... probably the best since
"null vs. exception" :-)

-- 

Patrick Dowler
Canadian Astronomy Data Centre


From dsmiley at mitre.org  Fri Sep  1 12:29:22 2000
From: dsmiley at mitre.org (David W. Smiley)
Date: Fri Aug  6 17:04:46 2004
Subject: [jdom-interest] children as List
References: <200009011735.LAA10878@dorothy.denveronline.net>
Message-ID: <39B00392.240B0F2D@mitre.org>

> 
>         How about creating a tagging interface (like Serializable) instead
> of 
> unifying the class hierarchy? This way, anything that wants to operate on 
> just JDOM nodes (and not just a specific class of JDOM nodes) can be sure 
> it's got one by testing for the tag. And it provides a useful place to put 
> whatever functionality may be common (such as getParent()) if we do decide 
> to unify the hierarchy.

	This sounds good to me; but the problem is that "String" is being used
as a node and therefore can't implement anything.  This could be solved
with a "Text" class that did implement "Node" but unfortunately the
powers that be (Brett, Elliott & the gang) do not like this.
	_I_ do think that a "Text" class would be a good idea; especially if
Element.getContent() would be defined to return the String value of the
Text if the content is a Text.  That looks like a good compromise to me
and adds type safety.  And instead of adding "Object" to an Element, you
add "Node".  That add method could be overloaded to accept a String
which will be converted to a Text Node.  Damn this sounds like a good
idea!  I can think a few methods that Node would have: toSerializedForm,
getParent, and perhaps getRootElement.  Even if it has no methods at
all, a Node class is a good idea.  Attributes should probably not
implement node even though they have a parent.

-- David Smiley


From dsmiley at mitre.org  Fri Sep  1 12:33:32 2000
From: dsmiley at mitre.org (David W. Smiley)
Date: Fri Aug  6 17:04:46 2004
Subject: [jdom-interest] Re: Fast or Safe?
References: <200009011735.LAA10878@dorothy.denveronline.net>
Message-ID: <39B0048C.1E7B557A@mitre.org>

> I wonder what percentage of the programs using JDOM are only using it to
> parse
> and extract information from an XML file by using a SAXBuilder or
> DOMBuilder, and
> therefore do not have any line of code where they explicitly create an
> Element
> (or Attribute, etc.). If SAXBuilder and DOMBuilder use a default factory
> unless told
> otherwise, then none of those programs would be affected.
> -- 
> 
> Gerardo Horvilleur
> mago@mail.internet.com.mx

It's probably a small amount and will remain to be.  Regardless; JDOM is
in beta and I think any change deemed for the better should be made now
while we can before we lock ourselves in.

-- David Smiley


From arosen at silverstream.com  Fri Sep  1 12:47:29 2000
From: arosen at silverstream.com (Rosen, Alex)
Date: Fri Aug  6 17:04:46 2004
Subject: [jdom-interest] children as List
In-Reply-To: <200009011735.LAA10887@dorothy.denveronline.net>
Message-ID: <003501c0144d$76d37220$8064810a@silverstream.com>

> What is the definition of List if not an
> ordered set of items, the items  normally being called the children
> of the list? Element contains children in a particular order. Things
> that have ordered children are lists. Therefore Element is a list.
> QED.

The things in a List are not usually called its children, but its elements or contents.
(Talk about overloaded words - maybe "items" is better here.) So the system you propose
would mean that you'd ask for an Element's second item, not its second child, which
feels wrong.

A List *contains* things. You *could* say that an Element contains other Elements, but
it's much more natural to say that the Elements are children of the parent Element.
When I think of a List, I think of a long, rectangular box with other boxes inside;
when I think of Elements, I think of a box with other boxes drawn below it, as
children.

To me, the more relevent problem is that you'd get rid of the word "child" from the
code:

(1) element.getChildren().get(2)
(2) element.getChild(2)
(3) element.get(2)

In the last case, what you're getting from the element is not obvious. As someone
pointed out, since an Element is a container for Attributes too, this seems like a
deal-breaker for me. The first two choices are much clearer.

--Alex

From Brad.Morgan at e-pubcorp.com  Fri Sep  1 12:57:59 2000
From: Brad.Morgan at e-pubcorp.com (Brad Morgan)
Date: Fri Aug  6 17:04:46 2004
Subject: [jdom-interest] XMLOutputter documentation doesn't match the code.
Message-ID: <NDBBLFGNKKGCBIJEAIJBIELFCGAA.Brad.Morgan@e-pubcorp.com>

I guess I'm a bit confused.  I'm behind a firewall so the command line CVS
doesn't work for me.

I go to the Web interface and it claims to build archives every night at
00:00 UTC and if I drill down to XMLOutputter.java it claims the file is 9
days old so the archive I downloaded yesterday should be up to date.

Just for fun I downloaded the "latest" XMLOutputter.java again today and now
I get the following error.  What's going on?

D:\Jdom>build
JDOM Build System
-------------------
Building with classpath
D:\JDK1.3\lib\tools.jar;.\lib\xerces.jar;.\lib\ant.jar;
Starting Ant...
Buildfile: build.xml
Project base dir set to: D:\Jdom
Executing Target: init
----------- JDOM 1.0beta4 [2000] ------------
Executing Target: prepare
Executing Target: prepare-src
Copying 1 files to D:\Jdom\build\src
Executing Target: compile
Compiling 1 source files to D:\Jdom\build\classes
D:\Jdom\build\src\org\jdom\output\XMLOutputter.java:402: No variable
XML_NAMESPA
CE defined in class org.jdom.Namespace.
            (ns != Namespace.XML_NAMESPACE) &&
                            ^
D:\Jdom\build\src\org\jdom\output\XMLOutputter.java:514: No variable
XML_NAMESPA
CE defined in class org.jdom.Namespace.
                (ns != Namespace.XML_NAMESPACE) &&
                                ^
2 errors
BUILD FATAL ERROR: Compile failed, messages should have been provided.
D:\Jdom>


Brad Morgan
e-Publishing Corp.

Email: Brad.Morgan@e-pubcorp.com
Phone: (719)593-7377 x35
Fax: (719)593-2996

e-Publishing Corp. is a BroadVision company
NOTICE: This message is intended only for the use of the Addressee and may
contain information that is PRIVILEGED and CONFIDENTIAL. If you are not the
intended recipient, dissemination of this communication is prohibited. If
you have received this communication in error, please erase all copies of
the message and its attachments and notify us immediately.



-----Original Message-----
From: jdom-interest-admin@jdom.org
[mailto:jdom-interest-admin@jdom.org]On Behalf Of
philip.nelson@omniresources.com
Sent: Friday, September 01, 2000 6:23 AM
To: Brad.Morgan@e-pubcorp.com; jdom-interest@jdom.org
Subject: RE: [jdom-interest] XMLOutputter documentation doesn't match
the code.



> The Javadoc documentation states that XMLOutputter() defaults
> to two space
> indent and new lines.  The code appears to implement no
> indent and no new
> lines.
>

This is already fixed in the CVS version ;)
_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com


From Murray.Altheim at eng.sun.com  Fri Sep  1 13:25:21 2000
From: Murray.Altheim at eng.sun.com (Murray Altheim)
Date: Fri Aug  6 17:04:46 2004
Subject: [jdom-interest] children as List
References: <003501c0144d$76d37220$8064810a@silverstream.com>
Message-ID: <39B010B1.870BE88B@eng.sun.com>

"Rosen, Alex" wrote:
> 
> > What is the definition of List if not an
> > ordered set of items, the items  normally being called the children
> > of the list? Element contains children in a particular order. Things
> > that have ordered children are lists. Therefore Element is a list.
> > QED.
> 
> The things in a List are not usually called its children, but its elements or contents.
> (Talk about overloaded words - maybe "items" is better here.) So the system you propose
> would mean that you'd ask for an Element's second item, not its second child, which
> feels wrong.
> 
> A List *contains* things. You *could* say that an Element contains other Elements, but
> it's much more natural to say that the Elements are children of the parent Element.
> When I think of a List, I think of a long, rectangular box with other boxes inside;
> when I think of Elements, I think of a box with other boxes drawn below it, as
> children.
> 
> To me, the more relevent problem is that you'd get rid of the word
> "child" from the code:
[...]

I'd really prefer we not do that.

You're using language regarding markup in a way that is very inconsistent
with my experience, and seemingly different from the way it is commonly
used in SGML and XML specifications. Perhaps a look at the XPath 
specification [XPATH] would provide some hints on how the W3C (and by 
extension) a substantial plurality of the XML community uses language.

An element may contain children. If the element type happens to 
semantically represent a list (which typically has 'list items'), its
children usually include elements that represent list items. This is
pretty clear from DocBook, for example.

Murray

[XPATH] http://www.w3.org/TR/xpath
...........................................................................
Murray Altheim, SGML/XML Grease Monkey     <mailto:altheim&#64;eng.sun.com>
XML Technology Center
Sun Microsystems, 1601 Willow Rd., MS UMPK17-102, Menlo Park, CA 94025

      In the evening
      The rice leaves in the garden
      Rustle in the autumn wind
      That blows through my reed hut.  -- Minamoto no Tsunenobu

From dsmiley at mitre.org  Fri Sep  1 14:09:28 2000
From: dsmiley at mitre.org (David W. Smiley)
Date: Fri Aug  6 17:04:46 2004
Subject: [jdom-interest] Re: jdom-interest digest, Vol 1 #194 - 17 msgs
References: <200009011735.LAA10878@dorothy.denveronline.net>
Message-ID: <39B01B08.BABB420E@mitre.org>

> >I'm not sure it's the right thing to go this way but let's look it
> >over.  I don't see what bugs you'd have when moving elements between
> >docs.  The simple idea is that if you have
> >
> ><foo:parent>
> >  <foo:child/>
> ></foo:parent>
> >
> >When you say parent.getChild("child") it's kinda natural for the
> >unspecified namespace of "child" to be the same as the parent, not the
> >no-namespace.  It's a simple way of thinking: ask Bob Jones about his
> >kid Billy and he naturally refers to the Billy in the Jones namespace.
> >:-)

Right :-)
> 
> Bugs or no bugs, this just doesn't seem obvious to me. I'd rather 
> explicitly specify my namespaces.

	Do you refer to your mother by her full name?  Does your Java code use
fully qualified package names always?

>I think this is going to cause big, 
> unexpected problems for programmers when they encounter documents 
> where the children don't have the same namespaces as the parent.

	It's hard to imagine "big unexpected problems" arising from this; you'd
quickly see your error after the first test-run.  The only thing that
makes me weary about this whole discussion is that I don't know that
much about xml namespaces (I have read some of the FAQ).  However I have
a strong feeling that namespaces should work how I am proposing it
should since I think namespaces should work in a way similar to other
applications of a name space that I am familiar with (ex: last names,
Java packages).  **The rough rule I mean when I said "works the same" is
that one shouldn't have to get overly specific about a name if a context
can be assummed.**  This doesn't hold for the serialized form of an XML
document (since you must put the prefix everywhere it should apply (i.e.
in scope) according to the spec), but it sure as hell would make it
convenient if within JDOM I wouldn't have to be so specific all the
time.  This is another way JDOM could become a better DOM, and XML for
that matter for ease in specifying namespaces :-)

	Imagine JDOM working roughly like this:
(1)Elements are created with a null namespace field if none is specified
in the constructor.
(2)Elements have a getNamespace() method that would work much like my
getRootElement() method did in my pseuodocode earlier.  That is,
recursively traverses ancestors, starting with itself, looking for a
namespace field that is not null and then returns it (possibly being
null).
(3)When an element is added to another element:
 if the namespace field of the added element is null, leave it null
(inheritance)
 if the namespace field of the added element is NOT null, then call
getNamespace on the new parent.  If it is the same namespace as the
added element's namespace field, then set the namespace of the added
element's namespace field to null (inheritance), otherwise leave it as
is.
(3)If an element is removed:
 if the namespace field of the removed element is null, then call
getNamespace on the parent of the removed element, and set the namespace
field of the removed element to that value.
 if the namespace field of the removed element is NOT null, then leave
it as is.
(4)If an element is cloned/copied:
 (works like removal but on a copy and without the actual removal)
(5)There is an instance of Namespace that represents the "Null XML
Namespace" --that is, a lack of a namespace
(6)The namespace behavior of Elements as described here applies to
Attributes in the same way (where appropriate).
(7)When serializing a document in which the root element has null for
its namespace field, the Null XML Namespace is assumed (the field is
_not_ set to this).
(8) "xmlns" and "xmlns:" prefixed attributes are considered transient. 
They aren't really there (i.e. detectable by the api), but it is visible
in the serialized form of an xml document.

Questions?  Comments?

Oh, and I agree with what Peter V. Gadjokov had to say about namespaces
in [Re: Namespace patch].  It is a tad confusing, but are you simply
saying that Namespaces should be distinguishable via the URI and not the
prefix?  And that Element.equals and hashcode would test against that
URI and the element's name?  That would be consistent with what the XML
Namespace FAQ says about the issue; see this section:
http://www.informatik.tu-darmstadt.de/DVS1/staff/bourret/xml/NamespacesFAQ.htm#q3_2

-- David Smiley


From Kevin.Hunt at ariba.com  Fri Sep  1 14:06:02 2000
From: Kevin.Hunt at ariba.com (Kevin Hunt)
Date: Fri Aug  6 17:04:46 2004
Subject: [jdom-interest] Re: Fast or Safe?
Message-ID: <271DE2625FD4D311949B009027F43B9F01DF2550@us-mtvmail2.ariba.com>

Just a lurker on the list, but...

My vote is for no factory for element creation, and little or no up-tree
checking.  What drew me to JDOM in the first place were its simplicity (I
can teach a Java newbie how it works in no time; a factory is a higher-level
concept and removes the "new" syntax that people are used to when creating
new objects), and its speed (heck, even the O'Reilly book says it's nearly
as fast as SAX).  I think we're making this overcomplicated for the
relatively small number of problems that would arise.

Why not just throw an exception when XMLOutputter hits an element it already
touched?  That would at least alert the programmer that they're
creating/adding elements in a bad way.  Or perhaps add a method to Document
that would remove any infinite element recursion?
-kevin hunt
---
This message does not represent the views of Ariba...

> -----Original Message-----
> From: jdom-interest-admin@jdom.org
> [mailto:jdom-interest-admin@jdom.org]On Behalf Of David W. Smiley
> Sent: Friday, September 01, 2000 12:34 PM
> To: mago@mail.internet.com.mx
> Cc: jdom-interest@jdom.org
> Subject: Re: [jdom-interest] Re: Fast or Safe?
> 
> 
> > I wonder what percentage of the programs using JDOM are 
> only using it to
> > parse
> > and extract information from an XML file by using a SAXBuilder or
> > DOMBuilder, and
> > therefore do not have any line of code where they 
> explicitly create an
> > Element
> > (or Attribute, etc.). If SAXBuilder and DOMBuilder use a 
> default factory
> > unless told
> > otherwise, then none of those programs would be affected.
> > -- 
> > 
> > Gerardo Horvilleur
> > mago@mail.internet.com.mx
> 
> It's probably a small amount and will remain to be.  
> Regardless; JDOM is
> in beta and I think any change deemed for the better should 
> be made now
> while we can before we lock ourselves in.
> 
> -- David Smiley
> 
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/yo
uraddr@yourhost.com


From Patrick.Dowler at nrc.ca  Fri Sep  1 14:17:28 2000
From: Patrick.Dowler at nrc.ca (Patrick Dowler)
Date: Fri Aug  6 17:04:46 2004
Subject: [jdom-interest] children as List
In-Reply-To: <003501c0144d$76d37220$8064810a@silverstream.com>
References: <003501c0144d$76d37220$8064810a@silverstream.com>
Message-ID: <0009011420270F.04558@kitasoo.hia.nrc.ca>

On Fri, 01 Sep 2000, you wrote:
> > What is the definition of List if not an
> > ordered set of items, the items  normally being called the children
> > of the list? Element contains children in a particular order. Things
> > that have ordered children are lists. Therefore Element is a list.
> > QED.
> 
> The things in a List are not usually called its children, but its elements or contents.
> (Talk about overloaded words - maybe "items" is better here.) So the system you propose
> would mean that you'd ask for an Element's second item, not its second child, which
> feels wrong.
> 
> A List *contains* things. You *could* say that an Element contains other Elements, but
> it's much more natural to say that the Elements are children of the parent Element.
> When I think of a List, I think of a long, rectangular box with other boxes inside;
> when I think of Elements, I think of a box with other boxes drawn below it, as
> children.

On the contrary, in simple XML like

<foo>
	<bar/>
</foo>

it is clear that element "foo" contains element "bar". 

--

Patrick Dowler
Canadian Astronomy Data Centre


From Haruki_Zaemon at hotmail.com  Fri Sep  1 14:26:49 2000
From: Haruki_Zaemon at hotmail.com (Simon Harris)
Date: Fri Aug  6 17:04:46 2004
Subject: [jdom-interest] Re: Fast or Safe?
References: <200008310604.AAA16501@dorothy.denveronline.net> <0008311810480V.00913@excalibur.peernet> <39AEF686.226AB02A@mail.internet.com.mx> <0008312231300W.00913@excalibur.peernet> <39AF9B2B.EA796FF1@mail.internet.com.mx>
Message-ID: <OE52PDqqgNjWOiy54Dg000002d0@hotmail.com>

We create new Elements and Attributes all the time. However converting from
"new Element" to "factory.newElement" would be as simple as anything.

I'd fully support the use of factories as we often have situations where we
would like to have our own Elements created during parsing.

If the interfaces were named IElement and IAttribute and Element and
Attribute were left as default implementations, then no code changes would
be required :)

Simon.

----- Original Message -----
From: "Gerardo Horvilleur" <mago@mail.internet.com.mx>
To: "Trebor A. Rude" <trebor@bwn.net>
Cc: <jdom-interest@jdom.org>
Sent: Friday, September 01, 2000 11:03 PM
Subject: Re: [jdom-interest] Re: Fast or Safe?


> > >It would be something like: Element foo = factory.newElement("foo")
> > >which seems reasonable enough to me. It is not too different from
> > >what we have right now and it makes it possible to have multiple
> > >implementations.
> >
> >         It's quite reasonable, my only concern is that it probably
breaks all
> > existing code, which we may not want to do. Fortunately we're in the
> > pre-1.0 stage, and it's easier to justify the large change. Brett?
Jason?
> > What do you think?
> >
>
> I wonder what percentage of the programs using JDOM are only using it to
parse
> and extract information from an XML file by using a SAXBuilder or
DOMBuilder, and
> therefore do not have any line of code where they explicitly create an
Element
> (or Attribute, etc.). If SAXBuilder and DOMBuilder use a default factory
unless told
> otherwise, then none of those programs would be affected.
> --
>
> Gerardo Horvilleur
> mago@mail.internet.com.mx
> _______________________________________________
> To control your jdom-interest membership:
>
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com
>

From Haruki_Zaemon at hotmail.com  Fri Sep  1 14:28:58 2000
From: Haruki_Zaemon at hotmail.com (Simon Harris)
Date: Fri Aug  6 17:04:46 2004
Subject: [jdom-interest] children as List
References: <03AC580B0983D311BD370050043724E901363BCC@TC-MAIL01> <00090107465500.00871@excalibur.peernet>
Message-ID: <OE33NPPzQT456UnHAaa000001b9@hotmail.com>

IMHO A great idea. I'm a big fan of interfaces. Use interfaces wherever
possible.

Simon.
----- Original Message -----
From: "Trebor A. Rude" <trebor@bwn.net>
To: "Cameron Smith" <cameron.smith@entranet.co.uk>; <jdom-interest@jdom.org>
Sent: Saturday, September 02, 2000 12:46 AM
Subject: Re: [jdom-interest] children as List


> On Fri, 01 Sep 2000, Cameron Smith wrote:
>
> >Another issue was ClassCastExceptions.  I think this is more an issue of
> >whether or not there should be a unified class hierarchy in JDom, so that
> >everything can be safely cast to 'Element', (like Node in DOM) than an
> > issue about where to put List behaviour.
>
> How about creating a tagging interface (like Serializable) instead of
> unifying the class hierarchy? This way, anything that wants to operate on
> just JDOM nodes (and not just a specific class of JDOM nodes) can be sure
> it's got one by testing for the tag. And it provides a useful place to put
> whatever functionality may be common (such as getParent()) if we do decide
> to unify the hierarchy.
>
> --
> Trebor A. Rude
> trebor@bwn.net
> Registered Linux User #89308
> http://counter.li.org/
> _______________________________________________
> To control your jdom-interest membership:
>
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com
>

From Haruki_Zaemon at hotmail.com  Fri Sep  1 14:48:21 2000
From: Haruki_Zaemon at hotmail.com (Simon Harris)
Date: Fri Aug  6 17:04:46 2004
Subject: [jdom-interest] Re: Fast or Safe?
References: <200008310604.AAA16501@dorothy.denveronline.net> <0008311810480V.00913@excalibur.peernet> <39AEF686.226AB02A@mail.internet.com.mx> <0008312231300W.00913@excalibur.peernet> <39AFC15D.5828AB7@lutris.com>
Message-ID: <OE54AitVGeSJIEoPXCF00000184@hotmail.com>

I love JDOM!!!! The major problems that I see JDOM solves over regular DOM
are:

    Support for collections, etc which most java programmers are used to and
not some shonky NodeList invented by a commitee with method names like
getNextSibling(), etc.

    Distinction between Elements, Attributes, etc.

    Text value of Elements as a single string and not some shonky TextNode

    Speed!!!

Unless I'm missing something, I don't see the problem with factories. As its
stands now I go through hoops to essentially extend Element and Attribute
and have JDOM use these in any useful way. If JDOM had a few interfaces and
factories and a default implementation of all these, I (and I suspect many
others) would never look back.

For example:

    Have two new interfaces IElement and IAttribute that return IElements
and IAttributes instead of Elements and Attributes

    Leave the existing classes (Element, Attribute, etc) as default
implementations of two new interfaces. This way I can still use Element foo
= new Element("foo") or still better IElement foo = new Element("foo").

    Have the Builder and Outputter accept a factory on construction. Or use
a default factory from the default constructor.

To address your concerns over existing code, its a simple as:

    Globally replace new Element with new XXXXElementXXX

    Globally replace Element (whole word only) to IElement

    Globally replace new XXXXElementXXXX to new Element

and voila we now use the new interfaces AND factories.

Even if we named the interfaces Element and Attribute and renamed the
existing classes Element and Attribute to DefaultElement and
DefaultAttribute respectively, I don't see the big deal WRT existing code.
These kind of code changes can be done all at once with very little effort.

Simon.

----- Original Message -----
From: "Brett McLaughlin" <brett.mclaughlin@lutris.com>
Cc: <jdom-interest@jdom.org>
Sent: Saturday, September 02, 2000 1:46 AM
Subject: Re: [jdom-interest] Re: Fast or Safe?


>
>
> "Trebor A. Rude" wrote:
> >
> > On Thu, 31 Aug 2000, Gerardo Horvilleur wrote:
> > >"Trebor A. Rude" wrote:
> > >>         Hmm, if we do that, we could create a sigleton factory class
> > >> to return you the proper implementation of the interface based on
some
> > >> settings it's got stored. At the very least, the programmer would be
> > >> forced to manually create objects of the correct implementation. Of
> > >> course, either way would probably break every existing JDOM program
out
> > >> there, as the "Element foo = new Element("foo");" idiom would break.
> > >> Even though we could, with the claim "the API is pre-1.0", I'm not
sure
> > >> many people would be very happy if we did that. Design wise, it
sounds
> > >> fine though.
> > >
> > >It would be something like: Element foo = factory.newElement("foo")
> > >which seems reasonable enough to me. It is not too different from
> > >what we have right now and it makes it possible to have multiple
> > >implementations.
> >
> >         It's quite reasonable, my only concern is that it probably
breaks all
> > existing code, which we may not want to do. Fortunately we're in the
> > pre-1.0 stage, and it's easier to justify the large change. Brett?
Jason?
> > What do you think?
>
> I continue to be against factories. It's unnecessary, I'm still
> convinced. Because it is the first option apparant to perform this task
> does not mean it is the best. It also makes implementation very messy,
> breaks all existing code in a /fundamental way/, causes many of the JDOM
> newbies to be totally lost, and AFAIK still doesn't add significant
> functionality.
>
> We went through this once every month or so, so I'd refer you to the
> archives for more details... I'm so far from being convinced this is
> even a good idea, though...
>
> -Brett
>
> >
> > --
> > Trebor A. Rude
> > trebor@bwn.net
> > Registered Linux User #89308
> > http://counter.li.org/
> > _______________________________________________
> > To control your jdom-interest membership:
> >
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com
>
> --
> Brett McLaughlin, Enhydra Strategist
> Lutris Technologies, Inc.
> 1200 Pacific Avenue, Suite 300
> Santa Cruz, CA 95060 USA
> http://www.lutris.com
> http://www.enhydra.org
> _______________________________________________
> To control your jdom-interest membership:
>
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com
>

From zeclarks at sprynet.com  Fri Sep  1 14:55:13 2000
From: zeclarks at sprynet.com (Stacie Clark)
Date: Fri Aug  6 17:04:46 2004
Subject: [jdom-interest] Javadocs
Message-ID: <39B025C1.12DC7F44@sprynet.com>

I noticed that there have been several questions about the Javadocs
being out of date.  I have a couple of bat files that live at the same
level as build files and will recurse through the directory structure
and build javadocs on the fly.  The bat files rely upon a java class
called JavadocRecurse that I found on the  Javadoc FAQ
(http://java.sun.com/products/jdk/javadoc/faq.html#recursesource)
(Kudos to James Schriever (jamess@sterwent.com), Sterling Wentworth
Corporation. who wrote the class). I can contribute these if anyone
thinks they would be useful to the project.

Stacie Clark
Senior Systems Architect
e-Numerate Solutions, Inc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://jdom.org/pipermail/jdom-interest/attachments/20000901/f0373c70/attachment.htm
From Haruki_Zaemon at hotmail.com  Fri Sep  1 14:56:55 2000
From: Haruki_Zaemon at hotmail.com (Simon Harris)
Date: Fri Aug  6 17:04:46 2004
Subject: [jdom-interest] Re: Fast or Safe?
References: <271DE2625FD4D311949B009027F43B9F01DF2550@us-mtvmail2.ariba.com>
Message-ID: <OE45RkeS8YkdavN3qlj0000019d@hotmail.com>

Why not have our cake and eat it too. If all you want is simple element and
attribute stuff, use new Element("foo"), new Attribute("bar") etc. And if
you want more flexibility use a factory. IMHO both these aims can be
achieved with very little effort by simply adding a factory that the build
and outputter use. if no factory is specified on construction, use the
DefaultFactory which just creates the existing Element and Attributes, etc
as I could do myself.

I have in a previous post suggest added interfaces into the equation but
there is no necessity to do so. If we force everyone to extend the existing
Element class (as an example) then we need no interfaces. I could build my
own factory that extends DefaultFactory and return my own class that extends
Element.

This solution DOESN'NT break ANY existing code AND allows me to add my own
sub-classes of Element, Attribute, whatever and have JDOM work with these as
natively as the existing classes.

Simon.

----- Original Message -----
From: "Kevin Hunt" <Kevin.Hunt@ariba.com>
To: <jdom-interest@jdom.org>
Sent: Saturday, September 02, 2000 8:06 AM
Subject: RE: [jdom-interest] Re: Fast or Safe?


> Just a lurker on the list, but...
>
> My vote is for no factory for element creation, and little or no up-tree
> checking.  What drew me to JDOM in the first place were its simplicity (I
> can teach a Java newbie how it works in no time; a factory is a
higher-level
> concept and removes the "new" syntax that people are used to when creating
> new objects), and its speed (heck, even the O'Reilly book says it's nearly
> as fast as SAX).  I think we're making this overcomplicated for the
> relatively small number of problems that would arise.
>
> Why not just throw an exception when XMLOutputter hits an element it
already
> touched?  That would at least alert the programmer that they're
> creating/adding elements in a bad way.  Or perhaps add a method to
Document
> that would remove any infinite element recursion?
> -kevin hunt
> ---
> This message does not represent the views of Ariba...
>
> > -----Original Message-----
> > From: jdom-interest-admin@jdom.org
> > [mailto:jdom-interest-admin@jdom.org]On Behalf Of David W. Smiley
> > Sent: Friday, September 01, 2000 12:34 PM
> > To: mago@mail.internet.com.mx
> > Cc: jdom-interest@jdom.org
> > Subject: Re: [jdom-interest] Re: Fast or Safe?
> >
> >
> > > I wonder what percentage of the programs using JDOM are
> > only using it to
> > > parse
> > > and extract information from an XML file by using a SAXBuilder or
> > > DOMBuilder, and
> > > therefore do not have any line of code where they
> > explicitly create an
> > > Element
> > > (or Attribute, etc.). If SAXBuilder and DOMBuilder use a
> > default factory
> > > unless told
> > > otherwise, then none of those programs would be affected.
> > > --
> > >
> > > Gerardo Horvilleur
> > > mago@mail.internet.com.mx
> >
> > It's probably a small amount and will remain to be.
> > Regardless; JDOM is
> > in beta and I think any change deemed for the better should
> > be made now
> > while we can before we lock ourselves in.
> >
> > -- David Smiley
> >
> > _______________________________________________
> > To control your jdom-interest membership:
> > http://lists.denveronline.net/mailman/options/jdom-interest/yo
> uraddr@yourhost.com
>
> _______________________________________________
> To control your jdom-interest membership:
>
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com
>

From brett.mclaughlin at lutris.com  Fri Sep  1 16:08:02 2000
From: brett.mclaughlin at lutris.com (Brett McLaughlin)
Date: Fri Aug  6 17:04:46 2004
Subject: [jdom-interest] Javadocs
References: <39B025C1.12DC7F44@sprynet.com>
Message-ID: <39B036D2.33DBAB11@lutris.com>


Stacie Clark wrote:
> 
> I noticed that there have been several questions about the Javadocs
> being out of date.  I have a couple of bat files that live at the same
> level as build files and will recurse through the directory structure
> and build javadocs on the fly.  The bat files rely upon a java class
> called JavadocRecurse that I found on the  Javadoc FAQ
> (http://java.sun.com/products/jdk/javadoc/faq.html#recursesource)
> (Kudos to James Schriever (jamess@sterwent.com), Sterling Wentworth
> Corporation. who wrote the class). I can contribute these if anyone
> thinks they would be useful to the project.

Ant builds javadoc as well as building the classes. We don't update the
Javadocs until we have milestones, so until Beta 5 comes out, there
won't be an update.

Thanks, though,
Brett

> 
> Stacie Clark
> Senior Systems Architect
> e-Numerate Solutions, Inc

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org

From zeclarks at sprynet.com  Fri Sep  1 17:33:02 2000
From: zeclarks at sprynet.com (Stacie Clark)
Date: Fri Aug  6 17:04:46 2004
Subject: [jdom-interest] Javadocs
References: <39B025C1.12DC7F44@sprynet.com> <39B036D2.33DBAB11@lutris.com>
Message-ID: <39B04ABD.D06579ED@sprynet.com>

Brett,
I realize that the official project JavaDocs will not be built until beta5. Rather, I
was suggesting that some users might prefer to build their own Javadocs in the
interim. The comments may be out of date but the api at least can be easily studied.
Since some of the users that have asked about the Javadocs have also said that they
are newbies to JDOM and some new to Java, it seemed reasonable to give them a
something to make their lives a little easier.

Brett McLaughlin wrote:

> Stacie Clark wrote:
> >
> > I noticed that there have been several questions about the Javadocs
> > being out of date.  I have a couple of bat files that live at the same
> > level as build files and will recurse through the directory structure
> > and build javadocs on the fly.  The bat files rely upon a java class
> > called JavadocRecurse that I found on the  Javadoc FAQ
> > (http://java.sun.com/products/jdk/javadoc/faq.html#recursesource)
> > (Kudos to James Schriever (jamess@sterwent.com), Sterling Wentworth
> > Corporation. who wrote the class). I can contribute these if anyone
> > thinks they would be useful to the project.
>
> Ant builds javadoc as well as building the classes. We don't update the
> Javadocs until we have milestones, so until Beta 5 comes out, there
> won't be an update.
>
> Thanks, though,
> Brett
>
> >
> > Stacie Clark
> > Senior Systems Architect
> > e-Numerate Solutions, Inc
>
> --
> Brett McLaughlin, Enhydra Strategist
> Lutris Technologies, Inc.
> 1200 Pacific Avenue, Suite 300
> Santa Cruz, CA 95060 USA
> http://www.lutris.com
> http://www.enhydra.org
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com


From jhunter at collab.net  Fri Sep  1 19:59:40 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:04:46 2004
Subject: [jdom-interest] insertChild in Element
References: <HCEOJDJOJJLJAFCILPLLKEBMCAAA.chris.hamersley@xmlglobal.com> <4.3.2.7.2.20000831083954.032dc1e0@mail.ic.net> <39AE73C2.5E408087@lutris.com> <0008311524350C.04558@kitasoo.hia.nrc.ca>
Message-ID: <39B06D1C.D98CD104@collab.net>

> In the "do what you like" category - unfortunately - is that you can add any
> arbitrary object. We lose type safety by exposing a live List to the programmer
> due to the non-type-safe containers :-( This is a very large blow to
> "good programming principles", IMO.

It's something that would be nice to avoid but it's endemic to the
language.  It's common in Java to use a List that (although the API
accepts Object) really only takes some special class or set of classes.

> Personally, I would not expose the List for this reason alone because the
> compiler can no longer catch simple errors. 

Raise your hand if you've added an object as a child of Element that
can't legally be a child of Element.  I doubt we'll see many hands. 
:-)  I agree we should check so you get a nice runtime error if you do
make the mistake, but is this really so likely to occur it's worth
adding a hunk of methods (and making lists immutable and changing the
core design of JDOM) so you get a compile time error?  I think not.

You could argue that JDOM should have immutable lists and that Element
should have every method that would change its child content and
attributes (dozens), but early on we favored delegating list management
to the Java-standard collections APIs, for various reasons like reducing
the size of the API, leveraging standard APIs, reducing the required
implementation code, and so on.

-jh-

From jhunter at collab.net  Fri Sep  1 00:42:02 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:04:46 2004
Subject: [jdom-interest] insertChild in Element
References: <784F51866054D4118E8A00508BDF581AC68B0B@emss02m02.ems.lmco.com>
Message-ID: <39AF5DCA.98CC82AB@collab.net>

BTW, in DOM the returned lists are live too.

-jh-

trebor.a.rude@lmco.com wrote:
> 
>         The counter to the argument against add() and such is that we
> actually return a PartialList (a JDOM-implemented subclass of LinkedList),
> so its implementations of the questionable functions could be changed to
> disallow anything "bad". The whole notion of a "live" list takes a little
> getting used to (simply because you just don't see it that often), but once
> you understand it, it makes a lot of sense. In my mind, the main argument
> for making Element implement List would be that the model would then be
> closer to the DOM, easing the transition for those used to that API.  But
> the function names of the List interface don't really make it clear that
> you're operating on children, as the functions in the DOM do. All in all, I
> don't think that compatibility with the DOM is that important, and in fact,
> I think it might be best if we removed some of the existing functions from
> Element (addContent/removeContent), and let those go through the list too.
> 
> Trebor A. Rude
> trebor.a.rude@lmco.com



From jhunter at collab.net  Fri Sep  1 00:44:50 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:04:46 2004
Subject: [jdom-interest] insertChild in Element
References: <784F51866054D4118E8A00508BDF581AC68B0C@emss02m02.ems.lmco.com>
Message-ID: <39AF5E72.F7965D65@collab.net>

>         I agree that the getting functions should stay, since they have no
> useful equivilents in the List API, but the addContent/removeContent
> functions do have equivilents in the List API 

No they don't.  The List API has no easy way to say "remove all elements
with the name 'foo'".  Things like that which are fairly common we have
convenience methods for.  The addContent() we need so you can do easy
method chaining.

> (and the add functions of the
> PartialList can be changed or overloaded so they only accept JDOM nodes,

You can't overload a method that takes Object to accept only JDOM nodes.

-jh-



From jhunter at collab.net  Fri Sep  1 02:36:15 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:04:46 2004
Subject: [jdom-interest] accessing Element.getChildren() elements with a 
 ListIterator
References: <39AEB11B.56E96D31@fool.com>
Message-ID: <39AF788F.D437E386@collab.net>

> I suppose i could do a toArray() on the List or something, but I thought that
> the reason for the List in the first place was so that you could do List style
> things to it.
> 
> Could someone please explain why the ListIterator approach doesn't work; if the
> fact that it doesn't work is a design decision, the basis for that decision; and
> if there are elegant alternative ways of doing this that I am missing, what
> those might be.

You don't say what doesn't work about it?  You mean it has no effect?

If so, it's likely PartialList needs to override listIterator() to
return an iterator smart enough to do the special work on the backling
list:  a PartialListIterator.  :-)

-jh-



From jhunter at collab.net  Fri Sep  1 20:12:13 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:04:46 2004
Subject: [jdom-interest] I'm 13 hrs behind
Message-ID: <39B0700D.7333F752@collab.net>

FYI, I just sent off a batch of messages written on a 13 hour flight. 
If I seem a half day behind the discussions, that's why.

-jh-

From trebor at bwn.net  Fri Sep  1 20:19:39 2000
From: trebor at bwn.net (Trebor A. Rude)
Date: Fri Aug  6 17:04:46 2004
Subject: [jdom-interest] insertChild in Element
In-Reply-To: <39AF5DCA.98CC82AB@collab.net>
References: <784F51866054D4118E8A00508BDF581AC68B0B@emss02m02.ems.lmco.com> <39AF5DCA.98CC82AB@collab.net>
Message-ID: <00090121193901.00871@excalibur.peernet>

	Yeah, they will track changes to the Elements they contain, but NodeList 
doesn't have any setting methods, so you can't change the tree using the 
list, like you can in JDOM.  That's what I meant.

On Fri, 01 Sep 2000, Jason Hunter wrote:
>BTW, in DOM the returned lists are live too.
>
>-jh-
>
>trebor.a.rude@lmco.com wrote:
>>         The counter to the argument against add() and such is that we
>> actually return a PartialList (a JDOM-implemented subclass of
>> LinkedList), so its implementations of the questionable functions could
>> be changed to disallow anything "bad". The whole notion of a "live"
>> list takes a little getting used to (simply because you just don't see
>> it that often), but once you understand it, it makes a lot of sense. In
>> my mind, the main argument for making Element implement List would be
>> that the model would then be closer to the DOM, easing the transition
>> for those used to that API.  But the function names of the List
>> interface don't really make it clear that you're operating on children,
>> as the functions in the DOM do. All in all, I don't think that
>> compatibility with the DOM is that important, and in fact, I think it
>> might be best if we removed some of the existing functions from Element
>> (addContent/removeContent), and let those go through the list too.

-- 
Trebor A. Rude
trebor@bwn.net
Registered Linux User #89308
http://counter.li.org/

From trebor at bwn.net  Fri Sep  1 20:27:23 2000
From: trebor at bwn.net (Trebor A. Rude)
Date: Fri Aug  6 17:04:46 2004
Subject: [jdom-interest] insertChild in Element
In-Reply-To: <39AF5E72.F7965D65@collab.net>
References: <784F51866054D4118E8A00508BDF581AC68B0C@emss02m02.ems.lmco.com> <39AF5E72.F7965D65@collab.net>
Message-ID: <00090121272302.00871@excalibur.peernet>

On Fri, 01 Sep 2000, Jason Hunter wrote:
>>         I agree that the getting functions should stay, since they have
>> no useful equivilents in the List API, but the addContent/removeContent
>> functions do have equivilents in the List API
>
>No they don't.  The List API has no easy way to say "remove all elements
>with the name 'foo'".  Things like that which are fairly common we have
>convenience methods for.  The addContent() we need so you can do easy
>method chaining.

	Ah, chaining. Keep forgetting about that, don't use it. Is it even 
possible with the DOM (if not, would explain why I don't use it, keep 
following the old patterns)? Don't remember.

>> (and the add functions of the
>> PartialList can be changed or overloaded so they only accept JDOM
>> nodes,
>
>You can't overload a method that takes Object to accept only JDOM nodes.

	No, but you could add methods that mimic the List methods and only take 
JDOM nodes. Of course, then you'd have to cast the List to a PartialList 
to use them, which really isn't any good, is it? Oh well, I just write 
whatever I happen to be thinking at the moment and trust the list to sort 
it out if I'm out of my mind. :)

-- 
Trebor A. Rude
trebor@bwn.net
Registered Linux User #89308
http://counter.li.org/

From jozart at csi.com  Sat Sep  2 06:48:22 2000
From: jozart at csi.com (Joseph Bowbeer)
Date: Fri Aug  6 17:04:46 2004
Subject: [jdom-interest] type safety: List<Element>
Message-ID: <000d01c014e4$75e00ad0$5c8a7cce@REPLICANT>

Type safety of collections is one of the issues that came up in the
"Fast or Safe" and "children as List" discussions.

I want to point out that work is underway to add generic types to Java.
(I believe the Collections API was designed with this eventuality in
mind.)  So it's fairly likely that List<Element> will be available to
JDOM as a first-class type in future versions of Java.

Check out JSR #14 (jsr_014_gener.html)

 http://java.sun.com/aboutJava/communityprocess/search.html

--
Joe Bowbeer




From Beau at PostTool.com  Sat Sep  2 19:06:49 2000
From: Beau at PostTool.com (Beau Bisquette)
Date: Fri Aug  6 17:04:46 2004
Subject: [jdom-interest] insertChild in Element
In-Reply-To: <00090121272302.00871@excalibur.peernet>
References: <39AF5E72.F7965D65@collab.net>
 <784F51866054D4118E8A00508BDF581AC68B0C@emss02m02.ems.lmco.com>
 <39AF5E72.F7965D65@collab.net>
Message-ID: <4.3.2.7.2.20000902190410.00af4720@mail.posttool.com>

Has anyone seen this error?

Internal Servlet Error:
java.util.ConcurrentModificationException
	at java.util.LinkedList$ListItr.checkForComodification(LinkedList.java:531)
	at java.util.LinkedList$ListItr.next(LinkedList.java:472)
	at org.jdom.Element.getChildren(Element.java:656)
	at org.jdom.Element.getChildren(Element.java:721)
	at org.jdom.Element.getChildren(Element.java:698)


Thanks,
Beau

Beau Bisquette
TPC Productions
Oakland, California


From jhunter at collab.net  Sat Sep  2 19:50:08 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:04:46 2004
Subject: [jdom-interest] Javadocs
References: <39B025C1.12DC7F44@sprynet.com> <39B036D2.33DBAB11@lutris.com> <39B04ABD.D06579ED@sprynet.com>
Message-ID: <39B1BC60.FAE6C6EE@collab.net>

> I realize that the official project JavaDocs will not be built until 
> beta5. Rather, I was suggesting that some users might prefer to 
> build their own Javadocs in the interim. 

What's wrong with "build javadoc"?  It's a standard build target we've
had since the beginning.

-jh-



From jhunter at collab.net  Sat Sep  2 20:17:37 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:04:46 2004
Subject: [jdom-interest] insertChild in Element
References: <39AF5E72.F7965D65@collab.net>
	 <784F51866054D4118E8A00508BDF581AC68B0C@emss02m02.ems.lmco.com>
	 <39AF5E72.F7965D65@collab.net> <4.3.2.7.2.20000902190410.00af4720@mail.posttool.com>
Message-ID: <39B1C2D1.FCB54798@collab.net>

Looks like you're walking an iterator and changing the List at the same
time.  Can't do that.

-jh-

Beau Bisquette wrote:
> 
> Has anyone seen this error?
> 
> Internal Servlet Error:
> java.util.ConcurrentModificationException
>         at java.util.LinkedList$ListItr.checkForComodification(LinkedList.java:531)
>         at java.util.LinkedList$ListItr.next(LinkedList.java:472)
>         at org.jdom.Element.getChildren(Element.java:656)
>         at org.jdom.Element.getChildren(Element.java:721)
>         at org.jdom.Element.getChildren(Element.java:698)
> 
> Thanks,
> Beau
> 
> Beau Bisquette
> TPC Productions
> Oakland, California
> 
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com



From Corbett.Klempay at trilogy.com  Sat Sep  2 21:22:32 2000
From: Corbett.Klempay at trilogy.com (Corbett.Klempay@trilogy.com)
Date: Fri Aug  6 17:04:46 2004
Subject: [jdom-interest] jdom/openxml
Message-ID: <OF19864D40.22C61881-ON8625694F.0017E4F1@trilogy.com>

Have any of your JDOM guys worked with/looked at OpenXML?  I stumbled
across it at work the other day; there isn't much in the way of included
documentation, so I can't totally assess (quickly) what it's shooting for,
but on first glance, looks like it's trying to for a similar set of goals
as JDOM is.  Anyone have any compare/contrast/info?

---
Corbett J. Klempay
Trilogy Software, Inc.
512.532.5176 (W) | 512.750.1372 (C)
corbett.klempay@trilogy.com



From brett.mclaughlin at lutris.com  Sun Sep  3 07:34:13 2000
From: brett.mclaughlin at lutris.com (Brett McLaughlin)
Date: Fri Aug  6 17:04:46 2004
Subject: [jdom-interest] jdom/openxml
References: <OF19864D40.22C61881-ON8625694F.0017E4F1@trilogy.com>
Message-ID: <39B26165.128C03E5@lutris.com>


Corbett.Klempay@trilogy.com wrote:
> 
> Have any of your JDOM guys worked with/looked at OpenXML?  I stumbled
> across it at work the other day; there isn't much in the way of included
> documentation, so I can't totally assess (quickly) what it's shooting for,
> but on first glance, looks like it's trying to for a similar set of goals
> as JDOM is.  Anyone have any compare/contrast/info?

openXML is an XML parser, that is now merged into the Xerces effort.
Totally different goals; openXML is like Xerces.

-Brett

> 
> ---
> Corbett J. Klempay
> Trilogy Software, Inc.
> 512.532.5176 (W) | 512.750.1372 (C)
> corbett.klempay@trilogy.com
> 
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org

From jhunter at collab.net  Sun Sep  3 12:42:50 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:04:46 2004
Subject: [jdom-interest] XMLOutputter documentation doesn't match the code.
References: <NDBBLFGNKKGCBIJEAIJBIELFCGAA.Brad.Morgan@e-pubcorp.com>
Message-ID: <39B2A9BA.97D23AE1@collab.net>

> Just for fun I downloaded the "latest" XMLOutputter.java again 
> today and now I get the following error.  What's going on?
> 
> D:\Jdom\build\src\org\jdom\output\XMLOutputter.java:402: No variable
> XML_NAMESPA
> CE defined in class org.jdom.Namespace.
>             (ns != Namespace.XML_NAMESPACE) &&

Dunno, the code works for me.  Try a clean build (build clean ; build).

-jh-



From jhunter at collab.net  Sun Sep  3 12:46:25 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:04:46 2004
Subject: [jdom-interest] children as List
References: <200009011735.LAA10878@dorothy.denveronline.net> <39B00392.240B0F2D@mitre.org>
Message-ID: <39B2AA91.2382F252@collab.net>

> This sounds good to me; but the problem is that "String" is 
> being used
> as a node and therefore can't implement anything.  This could 
> be solved
> with a "Text" class that did implement "Node" but unfortunately the
> powers that be (Brett, Elliott & the gang) do not like this.

Did you notice that someone else recently said that one reason they
liked JDOM was that it didn't have a Text wrapper around strings?  :-)

They also liked that it didn't require factories.  It's interesting that
both of these issues are being debated right now.

-jh-



From jhunter at collab.net  Sun Sep  3 12:48:48 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:04:46 2004
Subject: [jdom-interest] children as List
References: <003501c0144d$76d37220$8064810a@silverstream.com>
Message-ID: <39B2AB20.FB6D1B91@collab.net>

I'm in full agreement with Alex.  An Element being a List doesn't seem
like a good idea, for all the reasons Alex lays out.

-jh-

"Rosen, Alex" wrote:
> 
> > What is the definition of List if not an
> > ordered set of items, the items  normally being called the children
> > of the list? Element contains children in a particular order. Things
> > that have ordered children are lists. Therefore Element is a list.
> > QED.
> 
> The things in a List are not usually called its children, but its elements or contents.
> (Talk about overloaded words - maybe "items" is better here.) So the system you propose
> would mean that you'd ask for an Element's second item, not its second child, which
> feels wrong.
> 
> A List *contains* things. You *could* say that an Element contains other Elements, but
> it's much more natural to say that the Elements are children of the parent Element.
> When I think of a List, I think of a long, rectangular box with other boxes inside;
> when I think of Elements, I think of a box with other boxes drawn below it, as
> children.
> 
> To me, the more relevent problem is that you'd get rid of the word "child" from the
> code:
> 
> (1) element.getChildren().get(2)
> (2) element.getChild(2)
> (3) element.get(2)
> 
> In the last case, what you're getting from the element is not obvious. As someone
> pointed out, since an Element is a container for Attributes too, this seems like a
> deal-breaker for me. The first two choices are much clearer.
> 
> --Alex
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com



From jhunter at collab.net  Sun Sep  3 13:26:08 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:04:46 2004
Subject: [jdom-interest] API instability?
References: <51C6625F6F63D211853B0008C74C1A1EFA779E@corp-exchg-001.synchrony.net>
	 <39AE74C9.6D2C4954@lutris.com> <39AE8248.228AE913@collab.net> <v04210103b5d55191379b@[192.168.1.254]>
Message-ID: <39B2B3E0.FA3F3AE2@collab.net>

> >When you say parent.getChild("child") it's kinda natural for the
> >unspecified namespace of "child" to be the same as the parent, 
> 
> Bugs or no bugs, this just doesn't seem obvious to me. I'd rather
> explicitly specify my namespaces. I think this is going to cause big,
> unexpected problems for programmers when they encounter documents
> where the children don't have the same namespaces as the parent.

To argue against myself and with Elliotte, another problem with
getChild("child") using the parent's namespace is that

Element kid = new Element("kid");
parent.addContent(kid);
parent.getChild("kid");

*wouldn't work* if the parent was in a namespace.  That's pretty
confusing.  With the current code it would work because kid would be in
no namespace.  With namespaces it'd work too:

Element kid = new Element("kid", ns);
parent.addContent(kid);
parent.getChild("kid", ns);

-jh-



From Beau at PostTool.com  Sun Sep  3 14:40:01 2000
From: Beau at PostTool.com (Beau Bisquette)
Date: Fri Aug  6 17:04:46 2004
Subject: [jdom-interest] XMLOutputter error escaping this:   element.addContent("");
Message-ID: <4.3.2.7.2.20000902150151.023efd00@mail.posttool.com>

Dear Brett,

We have been experiencing difficulty outputting XML which has elements with 
empty content- not a new element with no content, but an element with "" 
content.
	ie: element.addContent(""); 		

so we propose this fix (or a more elegant rewrite...) starting at line 513 
of XMLOutputter,java

// Print the tag  with String on same line
// Example: tag name="value">content/tag>            			
// ** blows up if "" has been added as content to any element
// ** so we must test for funkiness.
// ** (david@posttool.com, will@posttool.com) String elementText = 
element.getText();
if ( ( elementText != null ) && !( elementText.equals( "" ) ) ) {
	out.write(">");
	out.write(escapeElementEntities(elementText));
	out.write("/");
	out.write(element.getQualifiedName());
	out.write(">");
} else {
	out.write(" />");
}
// end of test...

Thanks,
David & Will


Beau Bisquette
TPC Productions
Oakland, California


From jhunter at collab.net  Sun Sep  3 14:22:06 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:04:46 2004
Subject: [jdom-interest] Re: Fast or Safe?
References: <200008310604.AAA16501@dorothy.denveronline.net> <0008311810480V.00913@excalibur.peernet> <39AEF686.226AB02A@mail.internet.com.mx> <0008312231300W.00913@excalibur.peernet> <39AFC15D.5828AB7@lutris.com> <OE54AitVGeSJIEoPXCF00000184@hotmail.com>
Message-ID: <39B2C0FE.F970F3F0@collab.net>

> I love JDOM!!!! 

Me too.  :-)

>  Have two new interfaces IElement and IAttribute that return 
> IElements and IAttributes instead of Elements and Attributes

You can look to DOM for what the interface/factory model makes you do. 
For example, you can't just move an element from one doc to another, you
have to "import" the element.  You also have to use an existing document
to create a new element (document acts as the factory, making sure all
elts on a doc are of the same type).  What a pain.  I suspect a JDOM
interface/factory model would fall down the same pit.  Maybe a JDOM
baseclass/factory model would fare better, but I don't like the idea of
factories to handle core tasks unless it's 110% required to achieve a
base goal.

Simon's follow-on post about "having cake and eating it too" is closer
to what I think could be workable.  The issue is, if you create a
thread-safe implementation with SAXBuilder, how do you make sure that
the document stays thread-safe?  Only way is to do as DOM does and use
document as a factory and import content instead of directly adding
objects.  Ugh.  Is it really worth it?  I don't think so.  Hmm...

-jh-



From harish.kumar at patni.com  Sat Sep  2 01:49:22 2000
From: harish.kumar at patni.com (Harish Kumar)
Date: Fri Aug  6 17:04:46 2004
Subject: [jdom-interest] Problem of replacing Builder to DOMBuilder
Message-ID: <002701c014ba$b5916090$dd36a8c0@patni.com>

Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: Harish Kumar.vcf
Type: text/x-vcard
Size: 207 bytes
Desc: not available
Url : http://jdom.org/pipermail/jdom-interest/attachments/20000902/4b8f9ade/HarishKumar.vcf
From harish.kumar at patni.com  Sat Sep  2 01:00:10 2000
From: harish.kumar at patni.com (Harish Kumar)
Date: Fri Aug  6 17:04:46 2004
Subject: [jdom-interest] Errata
Message-ID: <001901c014b3$d8b5d2b0$dd36a8c0@patni.com>

Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: Harish Kumar.vcf
Type: text/x-vcard
Size: 207 bytes
Desc: not available
Url : http://jdom.org/pipermail/jdom-interest/attachments/20000902/ebb81429/HarishKumar.vcf
From harish.kumar at patni.com  Sat Sep  2 09:40:22 2000
From: harish.kumar at patni.com (Harish Kumar)
Date: Fri Aug  6 17:04:46 2004
Subject: [jdom-interest] Application Using JSP + XML + EJB using JDOM
Message-ID: <003f01c014fc$8215ba30$dd36a8c0@patni.com>

Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: Harish Kumar.vcf
Type: text/x-vcard
Size: 207 bytes
Desc: not available
Url : http://jdom.org/pipermail/jdom-interest/attachments/20000902/0422ba28/HarishKumar.vcf
From harish.kumar at patni.com  Sat Sep  2 10:48:35 2000
From: harish.kumar at patni.com (Harish Kumar)
Date: Fri Aug  6 17:04:46 2004
Subject: [jdom-interest] Fw: Problem on XML-RPC  Configuration File
Message-ID: <007b01c01506$09f06370$dd36a8c0@patni.com>

Correction:

            DOMBuilder builder =
                new DOMBuilder("org.jdom.adapters.XercesDOMAdapter");

            doc = builder.build(in); 


How can I put the explicit cast?

Regards

Harish



Hi

After making the correction Page No: 354( Java and Xml by Brett - Oreilly) for Writting XML From Java, When I am trying to compile the XmlRpcConfiguration.java file I am getting the following error:
 
E:\xml_test\jdom\src>javac XmlRpcConfiguration.java
XmlRpcConfiguration.java:195: Incompatible type for method. Explicit cast needed to convert java.io.Inpu
Stream to org.w3c.dom.Document.
            doc = builder.build(in);
                                ^
1 error
 
But when I have replace the colde  as shown below
 
           DOMBuilder builder =
                   new DOMBuilder("org.jdom.adapters.XercesDOMAdapter");
 
to        SAXBuilder builder = 
                   new SAXBuilder("org.jdom.adapters.XercesDOMAdapter");
 
It is compiling with the later code. What could be the reason?
 
But When I am Displaying the congiguration using the file "XmlRpcConfigurationServlet" (p.356), It is showing the following error:
 
Error: 500
Internal Servlet Error:

java.io.IOException: SAX2 driver class org.jdom.adapters.XercesDOMAdapter does not implement XMLReader: SAX2 driver class org.jdom.adapters.XercesDOMAdapter does not implement XMLReader
	at XmlRpcConfiguration.parseConfiguration(XmlRpcConfiguration.java, Compiled Code)
	at XmlRpcConfiguration.(XmlRpcConfiguration.java:83)
	at XmlRpcConfiguration.(XmlRpcConfiguration.java:62)
	at XmlRpcConfigurationServlet.doGet(XmlRpcConfigurationServlet.java, Compiled Code)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:715)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:840)
	at com.sun.web.core.ServletWrapper.handleRequest(ServletWrapper.java:155)
	at com.sun.web.core.InvokerServlet.service(InvokerServlet.java:168)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:840)
	at com.sun.web.core.ServletWrapper.handleRequest(ServletWrapper.java:155)
	at com.sun.web.core.Context.handleRequest(Context.java:414)
	at com.sun.web.server.ConnectionHandler.run(ConnectionHandler.java:139)


Any body has tried this example? Please advice me how to proceed?
 
Advance Thanks
 
Regards
 
Harish (mailto:  harish.kumar@patni.com)
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://jdom.org/pipermail/jdom-interest/attachments/20000902/22b857a0/attachment.htm
From harish.kumar at patni.com  Sat Sep  2 10:36:28 2000
From: harish.kumar at patni.com (Harish Kumar)
Date: Fri Aug  6 17:04:46 2004
Subject: [jdom-interest] Problem on XML-RPC  Configuration File
Message-ID: <006101c01504$587f15b0$dd36a8c0@patni.com>

Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: Harish Kumar.vcf
Type: text/x-vcard
Size: 207 bytes
Desc: not available
Url : http://jdom.org/pipermail/jdom-interest/attachments/20000902/410c536c/HarishKumar.vcf
From guyn at tantian.com  Mon Sep  4 01:28:34 2000
From: guyn at tantian.com (Guy Nirpaz)
Date: Fri Aug  6 17:04:47 2004
Subject: [jdom-interest] Application Using JSP + XML + EJB using JDOM
References: <003f01c014fc$8215ba30$dd36a8c0@patni.com>
Message-ID: <003201c0164a$1f220c90$080aa8c0@tantian.local>

Hi,

I've been using this combination for a while and it works just fine.
JDOM is much more straight forward to use than DOM.
I use JDOM to express XML data. My EJB's use XML for both input and output.
This means that the web tier is unaware of the representation of the data source.

Hope it helps,

Guy
  ----- Original Message ----- 
  From: Harish Kumar 
  To: jdom-interest@jdom.org 
  Sent: Saturday, September 02, 2000 6:40 PM
  Subject: [jdom-interest] Application Using JSP + XML + EJB using JDOM


  Hi 

  Any body have tried any application  "Using JSP + XML + EJB using JDOM"?
   
  Please give suggestions if any body tried these combination or similar.
   
  - Harish


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://jdom.org/pipermail/jdom-interest/attachments/20000904/43c85120/attachment.htm
From Daniel.Muhle at mettenmeier.de  Mon Sep  4 01:58:35 2000
From: Daniel.Muhle at mettenmeier.de (Muhle, Daniel)
Date: Fri Aug  6 17:04:47 2004
Subject: [jdom-interest] Finding the DTD
Message-ID: <33D3286F9722D411B6CB0000F8CB395C217512@exs_mm1.mettenmeier.de>

Hi,

I' ve been trying to write an little application that reads a config file
and presents the information 
to an servlet. When I'm trying to get a validating SAXBuilder and build the
Document in the Servlets 
Init-method,

   try {
      SAXBuilder builder = new SAXBuilder();
      Document doc =  builder.build(in);

 I get an FileNotFoundException, because the parser tries to find the DTD in
a directory relative to
the directory, the Webserver is started from. 
I wonder, why the parser isn't looking in the directory relative to the XML
file passed to the build(in) -
method. 

<!DOCTYPE MM:transform-config SYSTEM "DTD/tr-config.dtd"> .

Mit freundlichen Grüßen
Daniel Muhle
Mettenmeier GmbH, Software
mailto:Daniel.Muhle@mettenmeier.de
http://www.mettenmeier.de



From yusufg at outblaze.com  Mon Sep  4 03:14:53 2000
From: yusufg at outblaze.com (Yusuf Goolamabbas)
Date: Fri Aug  6 17:04:47 2004
Subject: [jdom-interest] How to get org.w3c.dom.Element to something which can be outputed by XMLOutputter
Message-ID: <20000904101453.30672.qmail@yusufg.portal2.com>

Hi, I am playing around with Apache SOAP and am trying to send a XML
file [using Literal XML encoding] across to a SOAP endpoint which
accepts an org.w3c.dom.Element as a parameter which is supposed to
represent the root of the XML tree

I am looking for a way to re-generate and output the XML file from
this parameter. I can't think of a way to get a org.jdom.Document from
a org.w3c.dom.Element. Any advice would be appreciated

Apache-SOAP :- http://xml.apache.org/soap

Regards, Yusuf

-- 
Yusuf Goolamabbas
yusufg@outblaze.com

From brett.mclaughlin at lutris.com  Mon Sep  4 07:31:56 2000
From: brett.mclaughlin at lutris.com (Brett McLaughlin)
Date: Fri Aug  6 17:04:47 2004
Subject: [jdom-interest] Errata
References: <001901c014b3$d8b5d2b0$dd36a8c0@patni.com>
Message-ID: <39B3B25C.D2F1A6D2@lutris.com>


> Harish Kumar wrote:
> 
> Hi
> 
> After implementing the corrections, as specified javaxml.800,ie:
> removing the import org.jdom.input.Builder and replacing the Builder
> with DOMBuilder, The following error is occuring after compiling:
> 
> E:\xml_test\jdom\src>javac DOMTest.java
> DOMTest.java:26: Incompatible type for method. Explicit cast needed to
> convert java.io.File to org.
> m.Document.
>       Document doc = builder.build(new File(args[0]));
>                                    ^
> 1 error
> 
> Please send me the suggestions to harish.kumar@patni.com

You need to get the latest version from CVS - you have beta 4, which is
really really old now ;-)

-Brett

> 
> Regards
> 
> Harish

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org

From brett.mclaughlin at lutris.com  Mon Sep  4 07:32:48 2000
From: brett.mclaughlin at lutris.com (Brett McLaughlin)
Date: Fri Aug  6 17:04:47 2004
Subject: [jdom-interest] Problem on XML-RPC  Configuration File
References: <006101c01504$587f15b0$dd36a8c0@patni.com>
Message-ID: <39B3B290.DC9CFEA5@lutris.com>


> Harish Kumar wrote:
> 
> Hi
> 
> After making the correction Page No: 354( Java and Xml by Brett -
> Oreilly) for Writting XML From Java, When I am trying to compile the
> XmlRpcConfiguration.java file I am getting the following error:
> 
> E:\xml_test\jdom\src>javac XmlRpcConfiguration.java
> XmlRpcConfiguration.java:195: Incompatible type for method. Explicit
> cast needed to convert java.io.Inpu
> Stream to org.w3c.dom.Document.
>             doc = builder.build(in);
>                                 ^
> 1 error
> 
> But when I have replace the colde  as shown below
> 
>            DOMBuilder builder =
>                    new
> DOMBuilder("org.jdom.adapters.XercesDOMAdapter");
> 
> to        SAXBuilder builder =
>                    new
> SAXBuilder("org.jdom.adapters.XercesDOMAdapter");
> 
> It is compiling with the later code. What could be the reason?

You need the latest code from CVS

-Brett

> 
> But When I am Displaying the congiguration using the file
> "XmlRpcConfigurationServlet" (p.356), It is showing the following
> error:
> 
> 
> Error: 500
> 
> Internal Servlet Error:
> 
> java.io.IOException: SAX2 driver class org.jdom.adapters.XercesDOMAdapter does not implement XMLReader: SAX2 driver class org.jdom.adapters.XercesDOMAdapter does not implement XMLReader
>         at XmlRpcConfiguration.parseConfiguration(XmlRpcConfiguration.java, Compiled Code)
>         at XmlRpcConfiguration.(XmlRpcConfiguration.java:83)
>         at XmlRpcConfiguration.(XmlRpcConfiguration.java:62)
>         at XmlRpcConfigurationServlet.doGet(XmlRpcConfigurationServlet.java, Compiled Code)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:715)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:840)
>         at com.sun.web.core.ServletWrapper.handleRequest(ServletWrapper.java:155)
>         at com.sun.web.core.InvokerServlet.service(InvokerServlet.java:168)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:840)
>         at com.sun.web.core.ServletWrapper.handleRequest(ServletWrapper.java:155)
>         at com.sun.web.core.Context.handleRequest(Context.java:414)
>         at com.sun.web.server.ConnectionHandler.run(ConnectionHandler.java:139)
> 
> Any body has tried this example? Please advice me how to proceed?
> 
> Advance Thanks
> 
> Regards
> 
> Harish (mailto:  harish.kumar@patni.com)
> 

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org

From harish.kumar at patni.com  Mon Sep  4 10:41:21 2000
From: harish.kumar at patni.com (Harish Kumar)
Date: Fri Aug  6 17:04:47 2004
Subject: [jdom-interest] Problem on XML-RPC  Configuration File
References: <006101c01504$587f15b0$dd36a8c0@patni.com> <39B3B290.DC9CFEA5@lutris.com>
Message-ID: <001001c01697$6198cad0$dd36a8c0@patni.com>

Hi Brett,

Let me thank you very much for the information regarding CVS, but I could
not able to log into to the system. I have downloaded the cvs.exe from
www.jdom.org , but I could not able to login to the system. It is saying the
time out. Hence I  clicked the link, "View the JDOM repository" and download
the jdom-complete.zip and I have added the ant.jar, xerces.jar,
collections.jar and jdom.jar into my classpath.

After this when I try to compile, XmlRpcConfiguration.java, It showing the
error for JDOMException, and I replaced the JDOMExeption(??) with Exception,
compiled.fter this I could  to compile the XmlRpcConfigurationServlet.java
also but, When I try to run the servlet using Jswdk1.0-1, I am getting the
following error:

command at the browser:
=================
http://localhost:8080/examples/servlet/XmlRpcConfigurationServlet

resulting output:
==========
Error : 500

Internal Servlet Error:

java.lang.NoSuchMethodError: org.w3c.dom.DocumentType: method
getPublicId()Ljava/lang/String; not found
 at org.jdom.input.DOMBuilder.buildTree(DOMBuilder.java, Compiled Code)
 at org.jdom.input.DOMBuilder.buildTree(DOMBuilder.java, Compiled Code)
 at org.jdom.input.DOMBuilder.build(DOMBuilder.java:174)
 at XmlRpcConfiguration.parseConfiguration(XmlRpcConfiguration.java,
Compiled Code)
 at XmlRpcConfiguration.(XmlRpcConfiguration.java:86)
 at XmlRpcConfiguration.(XmlRpcConfiguration.java:65)
 at XmlRpcConfigurationServlet.doGet(XmlRpcConfigurationServlet.java,
Compiled Code)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:715)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:840)
 at com.sun.web.core.ServletWrapper.handleRequest(ServletWrapper.java:155)
 at com.sun.web.core.InvokerServlet.service(InvokerServlet.java:168)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:840)
 at com.sun.web.core.ServletWrapper.handleRequest(ServletWrapper.java:155)
 at com.sun.web.core.Context.handleRequest(Context.java:414)
 at com.sun.web.server.ConnectionHandler.run(ConnectionHandler.java:139)

Thank you in Advance,

With Best Regards

Harish




----- Original Message -----
From: Brett McLaughlin <brett.mclaughlin@lutris.com>
To: Harish Kumar <harish.kumar@patni.com>
Cc: <jdom-interest@jdom.org>
Sent: Monday, September 04, 2000 8:02 PM
Subject: Re: [jdom-interest] Problem on XML-RPC Configuration File


>
>
> > Harish Kumar wrote:
> >
> > Hi
> >
> > After making the correction Page No: 354( Java and Xml by Brett -
> > Oreilly) for Writting XML From Java, When I am trying to compile the
> > XmlRpcConfiguration.java file I am getting the following error:
> >
> > E:\xml_test\jdom\src>javac XmlRpcConfiguration.java
> > XmlRpcConfiguration.java:195: Incompatible type for method. Explicit
> > cast needed to convert java.io.Inpu
> > Stream to org.w3c.dom.Document.
> >             doc = builder.build(in);
> >                                 ^
> > 1 error
> >
> > But when I have replace the colde  as shown below
> >
> >            DOMBuilder builder =
> >                    new
> > DOMBuilder("org.jdom.adapters.XercesDOMAdapter");
> >
> > to        SAXBuilder builder =
> >                    new
> > SAXBuilder("org.jdom.adapters.XercesDOMAdapter");
> >
> > It is compiling with the later code. What could be the reason?
>
> You need the latest code from CVS
>
> -Brett
>
> >
> > But When I am Displaying the congiguration using the file
> > "XmlRpcConfigurationServlet" (p.356), It is showing the following
> > error:
> >
> >
> > Error: 500
> >
> > Internal Servlet Error:
> >
> > java.io.IOException: SAX2 driver class
org.jdom.adapters.XercesDOMAdapter does not implement XMLReader: SAX2 driver
class org.jdom.adapters.XercesDOMAdapter does not implement XMLReader
> >         at
XmlRpcConfiguration.parseConfiguration(XmlRpcConfiguration.java, Compiled
Code)
> >         at XmlRpcConfiguration.(XmlRpcConfiguration.java:83)
> >         at XmlRpcConfiguration.(XmlRpcConfiguration.java:62)
> >         at
XmlRpcConfigurationServlet.doGet(XmlRpcConfigurationServlet.java, Compiled
Code)
> >         at javax.servlet.http.HttpServlet.service(HttpServlet.java:715)
> >         at javax.servlet.http.HttpServlet.service(HttpServlet.java:840)
> >         at
com.sun.web.core.ServletWrapper.handleRequest(ServletWrapper.java:155)
> >         at
com.sun.web.core.InvokerServlet.service(InvokerServlet.java:168)
> >         at javax.servlet.http.HttpServlet.service(HttpServlet.java:840)
> >         at
com.sun.web.core.ServletWrapper.handleRequest(ServletWrapper.java:155)
> >         at com.sun.web.core.Context.handleRequest(Context.java:414)
> >         at
com.sun.web.server.ConnectionHandler.run(ConnectionHandler.java:139)
> >
> > Any body has tried this example? Please advice me how to proceed?
> >
> > Advance Thanks
> >
> > Regards
> >
> > Harish (mailto:  harish.kumar@patni.com)
> >
>
> --
> Brett McLaughlin, Enhydra Strategist
> Lutris Technologies, Inc.
> 1200 Pacific Avenue, Suite 300
> Santa Cruz, CA 95060 USA
> http://www.lutris.com
> http://www.enhydra.org
> _______________________________________________
> To control your jdom-interest membership:
>
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com


From harish.kumar at patni.com  Mon Sep  4 10:49:16 2000
From: harish.kumar at patni.com (Harish Kumar)
Date: Fri Aug  6 17:04:47 2004
Subject: [jdom-interest] Will "obj1.equals(obj2)==true "  (Java-XML-Java)
References: <006101c01504$587f15b0$dd36a8c0@patni.com> <39B3B290.DC9CFEA5@lutris.com>
Message-ID: <001101c01698$7746e9b0$dd36a8c0@patni.com>

Hi

Will "obj1.equals(obj2)==true "  if I am creating an "test.xml" file using
the instance(object) "obj1" of a class "test.class" and creating an object
"obj2" of same class from same xml?

Please suggest how can I create test.xml direclty from a class test.class?
Does JDOM supports any API to do this?

Advance Thanks

Regards,

Harish



From brett.mclaughlin at lutris.com  Mon Sep  4 11:30:54 2000
From: brett.mclaughlin at lutris.com (Brett McLaughlin)
Date: Fri Aug  6 17:04:47 2004
Subject: [jdom-interest] Problem on XML-RPC  Configuration File
References: <006101c01504$587f15b0$dd36a8c0@patni.com> <39B3B290.DC9CFEA5@lutris.com> <001001c01697$6198cad0$dd36a8c0@patni.com>
Message-ID: <39B3EA5E.39FE916A@lutris.com>


Harish Kumar wrote:
> 
> Hi Brett,
> 
> Let me thank you very much for the information regarding CVS, but I could
> not able to log into to the system. I have downloaded the cvs.exe from
> www.jdom.org , but I could not able to login to the system. It is saying the
> time out. Hence I  clicked the link, "View the JDOM repository" and download
> the jdom-complete.zip and I have added the ant.jar, xerces.jar,
> collections.jar and jdom.jar into my classpath.

You have DOM Level 1 classes in your classpath ahead of xerces.jar - did
you ensure that xml.jar and projectx.jar and tr2.jar and other
variations are after xerces.jar in your servlet engine classpath? This
is detailed in Ch. 11, the XML-RPC chapter you are referring to. Get
xerces.jar ahead of those others and it will work.

-Brett

> 
> After this when I try to compile, XmlRpcConfiguration.java, It showing the
> error for JDOMException, and I replaced the JDOMExeption(??) with Exception,
> compiled.fter this I could  to compile the XmlRpcConfigurationServlet.java
> also but, When I try to run the servlet using Jswdk1.0-1, I am getting the
> following error:
> 
> command at the browser:
> =================
> http://localhost:8080/examples/servlet/XmlRpcConfigurationServlet
> 
> resulting output:
> ==========
> Error : 500
> 
> Internal Servlet Error:
> 
> java.lang.NoSuchMethodError: org.w3c.dom.DocumentType: method
> getPublicId()Ljava/lang/String; not found
>  at org.jdom.input.DOMBuilder.buildTree(DOMBuilder.java, Compiled Code)
>  at org.jdom.input.DOMBuilder.buildTree(DOMBuilder.java, Compiled Code)
>  at org.jdom.input.DOMBuilder.build(DOMBuilder.java:174)
>  at XmlRpcConfiguration.parseConfiguration(XmlRpcConfiguration.java,
> Compiled Code)
>  at XmlRpcConfiguration.(XmlRpcConfiguration.java:86)
>  at XmlRpcConfiguration.(XmlRpcConfiguration.java:65)
>  at XmlRpcConfigurationServlet.doGet(XmlRpcConfigurationServlet.java,
> Compiled Code)
>  at javax.servlet.http.HttpServlet.service(HttpServlet.java:715)
>  at javax.servlet.http.HttpServlet.service(HttpServlet.java:840)
>  at com.sun.web.core.ServletWrapper.handleRequest(ServletWrapper.java:155)
>  at com.sun.web.core.InvokerServlet.service(InvokerServlet.java:168)
>  at javax.servlet.http.HttpServlet.service(HttpServlet.java:840)
>  at com.sun.web.core.ServletWrapper.handleRequest(ServletWrapper.java:155)
>  at com.sun.web.core.Context.handleRequest(Context.java:414)
>  at com.sun.web.server.ConnectionHandler.run(ConnectionHandler.java:139)
> 
> Thank you in Advance,
> 
> With Best Regards
> 
> Harish
> 
> ----- Original Message -----
> From: Brett McLaughlin <brett.mclaughlin@lutris.com>
> To: Harish Kumar <harish.kumar@patni.com>
> Cc: <jdom-interest@jdom.org>
> Sent: Monday, September 04, 2000 8:02 PM
> Subject: Re: [jdom-interest] Problem on XML-RPC Configuration File
> 
> >
> >
> > > Harish Kumar wrote:
> > >
> > > Hi
> > >
> > > After making the correction Page No: 354( Java and Xml by Brett -
> > > Oreilly) for Writting XML From Java, When I am trying to compile the
> > > XmlRpcConfiguration.java file I am getting the following error:
> > >
> > > E:\xml_test\jdom\src>javac XmlRpcConfiguration.java
> > > XmlRpcConfiguration.java:195: Incompatible type for method. Explicit
> > > cast needed to convert java.io.Inpu
> > > Stream to org.w3c.dom.Document.
> > >             doc = builder.build(in);
> > >                                 ^
> > > 1 error
> > >
> > > But when I have replace the colde  as shown below
> > >
> > >            DOMBuilder builder =
> > >                    new
> > > DOMBuilder("org.jdom.adapters.XercesDOMAdapter");
> > >
> > > to        SAXBuilder builder =
> > >                    new
> > > SAXBuilder("org.jdom.adapters.XercesDOMAdapter");
> > >
> > > It is compiling with the later code. What could be the reason?
> >
> > You need the latest code from CVS
> >
> > -Brett
> >
> > >
> > > But When I am Displaying the congiguration using the file
> > > "XmlRpcConfigurationServlet" (p.356), It is showing the following
> > > error:
> > >
> > >
> > > Error: 500
> > >
> > > Internal Servlet Error:
> > >
> > > java.io.IOException: SAX2 driver class
> org.jdom.adapters.XercesDOMAdapter does not implement XMLReader: SAX2 driver
> class org.jdom.adapters.XercesDOMAdapter does not implement XMLReader
> > >         at
> XmlRpcConfiguration.parseConfiguration(XmlRpcConfiguration.java, Compiled
> Code)
> > >         at XmlRpcConfiguration.(XmlRpcConfiguration.java:83)
> > >         at XmlRpcConfiguration.(XmlRpcConfiguration.java:62)
> > >         at
> XmlRpcConfigurationServlet.doGet(XmlRpcConfigurationServlet.java, Compiled
> Code)
> > >         at javax.servlet.http.HttpServlet.service(HttpServlet.java:715)
> > >         at javax.servlet.http.HttpServlet.service(HttpServlet.java:840)
> > >         at
> com.sun.web.core.ServletWrapper.handleRequest(ServletWrapper.java:155)
> > >         at
> com.sun.web.core.InvokerServlet.service(InvokerServlet.java:168)
> > >         at javax.servlet.http.HttpServlet.service(HttpServlet.java:840)
> > >         at
> com.sun.web.core.ServletWrapper.handleRequest(ServletWrapper.java:155)
> > >         at com.sun.web.core.Context.handleRequest(Context.java:414)
> > >         at
> com.sun.web.server.ConnectionHandler.run(ConnectionHandler.java:139)
> > >
> > > Any body has tried this example? Please advice me how to proceed?
> > >
> > > Advance Thanks
> > >
> > > Regards
> > >
> > > Harish (mailto:  harish.kumar@patni.com)
> > >
> >
> > --
> > Brett McLaughlin, Enhydra Strategist
> > Lutris Technologies, Inc.
> > 1200 Pacific Avenue, Suite 300
> > Santa Cruz, CA 95060 USA
> > http://www.lutris.com
> > http://www.enhydra.org
> > _______________________________________________
> > To control your jdom-interest membership:
> >
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
> t.com

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org

From jhunter at collab.net  Mon Sep  4 13:28:35 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:04:47 2004
Subject: [jdom-interest] How to get org.w3c.dom.Element to something which 
 can be outputed by XMLOutputter
References: <20000904101453.30672.qmail@yusufg.portal2.com>
Message-ID: <39B405F3.DC127603@collab.net>

> I am looking for a way to re-generate and output the XML file from
> this parameter. I can't think of a way to get a org.jdom.Document from
> a org.w3c.dom.Element. Any advice would be appreciated

The best way is using org.jdom.Element
DOMBuilder.build(org.w3c.dom.Element).  That particular method is not
written yet but it's in our TODO to be done.  The code you need is in
DOMBuilder, it just needs to be broken out.  Feel free to help do that
breakout.

-jh-



From jhunter at collab.net  Mon Sep  4 13:50:01 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:04:47 2004
Subject: [jdom-interest] Finding the DTD
References: <33D3286F9722D411B6CB0000F8CB395C217512@exs_mm1.mettenmeier.de>
Message-ID: <39B40AF9.E95284EA@collab.net>

>       SAXBuilder builder = new SAXBuilder();
>       Document doc =  builder.build(in);
> 
>  I get an FileNotFoundException, because the parser tries to 
> find the DTD in a directory relative to
> the directory, the Webserver is started from.

That's why there's a build(InputStream, String) method.

-jh-


From brett.mclaughlin at lutris.com  Mon Sep  4 14:23:05 2000
From: brett.mclaughlin at lutris.com (Brett McLaughlin)
Date: Fri Aug  6 17:04:47 2004
Subject: [jdom-interest] Changes
Message-ID: <39B412B9.5949ECE@lutris.com>

All-

  I just made some additional changes/etc. to the JDOM tree.

* Implemented Elliotte's changes to XMLOutputter and Namespace to handle
more advanced prefix/URI mappings
* Added debugging into SAXBuidler (commented out) so I can check on the
Xerces bug with inline DOCTYPE declarations
* Updated xerces.jar to Xerces 1.2.0
* Updated TODO.txt

Please update your tree and check it all out... thanks!

-Brett

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org

From mago at mail.internet.com.mx  Mon Sep  4 22:35:51 2000
From: mago at mail.internet.com.mx (Gerardo Horvilleur)
Date: Fri Aug  6 17:04:47 2004
Subject: [jdom-interest] JDOM as a Database API?
Message-ID: <39B48637.7CA8E246@mail.internet.com.mx>

Have any of you thought about using JDOM as a Database API?

There are many applications were I would prefer to have an XML-based data model and use
JDOM to access the information rather tan store it in a RDBMS and have to use JDBC.

To test this idea I am planning to write a JDOM implementation where all the information
(Elements, Attributes, content, etc.) is stored in a RDBMS instead of using in-memory
data structures, but before I start I just wanted to check if anybody out there has already
done it.
-- 

Gerardo Horvilleur
mago@mail.internet.com.mx

From jhunter at collab.net  Mon Sep  4 23:02:46 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:04:47 2004
Subject: [jdom-interest] JDOM as a Database API?
References: <39B48637.7CA8E246@mail.internet.com.mx>
Message-ID: <39B48C86.A0382D31@collab.net>

There's ResultSetBuilder in jdom-contrib that's similar to this.  One
could imagine writing a corresponding Outputter.

-jh-


Gerardo Horvilleur wrote:
> 
> Have any of you thought about using JDOM as a Database API?
> 
> There are many applications were I would prefer to have an XML-based data model and use
> JDOM to access the information rather tan store it in a RDBMS and have to use JDBC.
> 
> To test this idea I am planning to write a JDOM implementation where all the information
> (Elements, Attributes, content, etc.) is stored in a RDBMS instead of using in-memory
> data structures, but before I start I just wanted to check if anybody out there has already
> done it.
> --
> 
> Gerardo Horvilleur
> mago@mail.internet.com.mx
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com

From mago at mail.internet.com.mx  Mon Sep  4 23:39:07 2000
From: mago at mail.internet.com.mx (Gerardo Horvilleur)
Date: Fri Aug  6 17:04:47 2004
Subject: [jdom-interest] JDOM as a Database API?
References: <39B48637.7CA8E246@mail.internet.com.mx> <39B48C86.A0382D31@collab.net>
Message-ID: <39B4950B.8A3953D9@mail.internet.com.mx>

Jason Hunter wrote:
> 
> There's ResultSetBuilder in jdom-contrib that's similar to this.  One
> could imagine writing a corresponding Outputter.

What I have in mind is something like this:

    // Create employees database
    Element employeesRoot = new Element("employees");
    Document employess = new Document(employeesRoot);

    // Create new employee
    Element employee = new Element("employee");
    employee.addAttribute("fistname", "John");
    employee.addAttribute("lastname", "Smith");
    employee.addAttribute("age", "31");
    // Note: all of the above could be sub-elements instead of attributes

    // Add employee to employees database
    employees.addContent(employee);

You wouldn't need to use any Builder or Outputter. As soon as an element is added
to a document it is automatically stored into the database.
-- 

Gerardo Horvilleur
mago@mail.internet.com.mx

From jhunter at collab.net  Mon Sep  4 23:48:58 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:04:47 2004
Subject: [jdom-interest] JDOM as a Database API?
References: <39B48637.7CA8E246@mail.internet.com.mx> <39B48C86.A0382D31@collab.net> <39B4950B.8A3953D9@mail.internet.com.mx>
Message-ID: <39B4975A.ECAA7F14@collab.net>

> You wouldn't need to use any Builder or Outputter. As soon as an element is added
> to a document it is automatically stored into the database.

Why use the JDOM API for the data manipulations?

-jh-

From guyn at tantian.com  Tue Sep  5 01:09:20 2000
From: guyn at tantian.com (Guy Nirpaz)
Date: Fri Aug  6 17:04:47 2004
Subject: [jdom-interest] Convert XML data to Java ojbects
Message-ID: <002f01c01710$99dce4c0$080aa8c0@tantian.local>

Hi all,

I wrote a simple utility that helps you convert XML data to instantiated
Java objects and vice-versa.
It uses a simple naming convention schema that can be overridden by a
configuration file.

In order to convert an XML file to a Java object you use something similar
to :
<code>
  XMLConversionRule rule = new DefaultXMLConversionRule ( new File
 "person_in.xml" ) ) ;
  XMLConvertor converter = new XMLConvertor () ;
  Object obj = converter.convert( doc.getRootElement() , rule ) ;
</code>

And for the opposite direction you use :
<code>
  ObjectConvertor converter = new ObjectConvertor () ;
  ObjectConversionRule rule = new DefaultObjectConversionRule ( new File
 "person_out.xml" ) ) ;
  Element root = converter.convert( person , rule );
</code>

I'm not sure if I should enclose a jar file to the entire list.
So if someone is interested, I'll be happy to contribute the code.

Hope you'll find it useful

Guy Nirpaz
Java Architect

Tantian Corp.
guyn@tantian.com


From mago at mail.internet.com.mx  Tue Sep  5 00:23:05 2000
From: mago at mail.internet.com.mx (Gerardo Horvilleur)
Date: Fri Aug  6 17:04:47 2004
Subject: [jdom-interest] JDOM as a Database API?
References: <39B48637.7CA8E246@mail.internet.com.mx> <39B48C86.A0382D31@collab.net> <39B4950B.8A3953D9@mail.internet.com.mx> <39B4975A.ECAA7F14@collab.net>
Message-ID: <39B49F59.EE58074@mail.internet.com.mx>

Jason Hunter wrote:
> 
> > You wouldn't need to use any Builder or Outputter. As soon as an element is added
> > to a document it is automatically stored into the database.
> 
> Why use the JDOM API for the data manipulations?
> 
> -jh-

Because:

   1. It is simple, and easy to use.

   2. It is flexible: it can be used to store/retrieve anything that could be
      represented as an XML document (or RDBMS).

   3. For an object oriented program it is more "natural" to build/traverse a JDOM
      tree than using JDBC to manipulate table rows in a RDBMS (you could also state
      this as: there is a lower "impedance mismatch" between Java and JDOM than
      between Java and a RDBMS).

   4. Better performance for very large XML documents because you only bring the data
      into RAM on an as-needed basis.
-- 

Gerardo Horvilleur
mago@mail.internet.com.mx

From donaldp at mad.scientist.com  Tue Sep  5 00:36:38 2000
From: donaldp at mad.scientist.com (donaldp@mad.scientist.com)
Date: Fri Aug  6 17:04:47 2004
Subject: [jdom-interest] JDOM as a Database API?
In-Reply-To: <39B49F59.EE58074@mail.internet.com.mx>
Message-ID: <Pine.LNX.4.21.0009051831240.15211-100000@latcs2.cs.latrobe.EDU.AU>

Hi,

it sounds like you are looking for some data binding type
functionality. This is already available from a number of
different sources. 

There is Village/Torque/town available via working-dogs.com
(I believe) and also included in Turbine project at
java.apache.org. 

There is also the JDO/various other data binding techniques
that bind data from dbs/xml files etc to objects and that is
available from exolabs (whose site seems to be down atm). Do
a search for exact URL.

On Tue, 5 Sep 2000, Gerardo Horvilleur wrote:

> Jason Hunter wrote:
> > 
> > > You wouldn't need to use any Builder or Outputter. As soon as an element is added
> > > to a document it is automatically stored into the database.
> > 
> > Why use the JDOM API for the data manipulations?
> > 
> > -jh-
> 
> Because:
> 
>    1. It is simple, and easy to use.
> 
>    2. It is flexible: it can be used to store/retrieve anything that could be
>       represented as an XML document (or RDBMS).
> 
>    3. For an object oriented program it is more "natural" to build/traverse a JDOM
>       tree than using JDBC to manipulate table rows in a RDBMS (you could also state
>       this as: there is a lower "impedance mismatch" between Java and JDOM than
>       between Java and a RDBMS).
> 
>    4. Better performance for very large XML documents because you only bring the data
>       into RAM on an as-needed basis.


Cheers,

Pete

*--------------------------------------------------*
| Latrobe University,     | Does the name 'Pavlov' |
| Bundoora, Australia     |    ring a bell ?       |
*--------------------------------------------------*


From mago at mail.internet.com.mx  Tue Sep  5 01:10:11 2000
From: mago at mail.internet.com.mx (Gerardo Horvilleur)
Date: Fri Aug  6 17:04:47 2004
Subject: [jdom-interest] JDOM as a Database API?
References: <Pine.LNX.4.21.0009051831240.15211-100000@latcs2.cs.latrobe.EDU.AU>
Message-ID: <39B4AA63.F9CC64EE@mail.internet.com.mx>

donaldp@mad.scientist.com wrote: 
> it sounds like you are looking for some data binding type
> functionality. This is already available from a number of
> different sources.
> 
> There is Village/Torque/town available via working-dogs.com
> (I believe) and also included in Turbine project at
> java.apache.org.


Yes, I do want something in the spirit of Village/Town but I don't
want the relational database model, I want the XML document model.

> There is also the JDO/various other data binding techniques
> that bind data from dbs/xml files etc to objects and that is
> available from exolabs (whose site seems to be down atm). Do
> a search for exact URL.

This looks more like what I am looking for. Their web site is
http://castor.exolab.org but unfortunately the site does
seem to be down.

Thanks,
-- 

Gerardo Horvilleur
mago@mail.internet.com.mx

From brett.mclaughlin at lutris.com  Tue Sep  5 02:16:59 2000
From: brett.mclaughlin at lutris.com (Brett McLaughlin)
Date: Fri Aug  6 17:04:47 2004
Subject: [jdom-interest] JDOM as a Database API?
References: <39B48637.7CA8E246@mail.internet.com.mx> <39B48C86.A0382D31@collab.net> <39B4950B.8A3953D9@mail.internet.com.mx>
Message-ID: <39B4BA0B.994E03E@lutris.com>


Gerardo Horvilleur wrote:
> 
> Jason Hunter wrote:
> >
> > There's ResultSetBuilder in jdom-contrib that's similar to this.  One
> > could imagine writing a corresponding Outputter.
> 
> What I have in mind is something like this:
> 
>     // Create employees database
>     Element employeesRoot = new Element("employees");
>     Document employess = new Document(employeesRoot);
> 
>     // Create new employee
>     Element employee = new Element("employee");
>     employee.addAttribute("fistname", "John");
>     employee.addAttribute("lastname", "Smith");
>     employee.addAttribute("age", "31");
>     // Note: all of the above could be sub-elements instead of attributes
> 
>     // Add employee to employees database
>     employees.addContent(employee);
> 
> You wouldn't need to use any Builder or Outputter. As soon as an element is added
> to a document it is automatically stored into the database.

I'm very much against this, for several reasons.

First, the core principle of JDOM is that it is an in-memory structure,
and is pure Java objects until it is outputted, and inputted. In other
words, a document doesn't have to be well-formed, valid, etc., except
when inpit and output occurs. Not tying the in-memory representation to
XML, databases, or anything else keeps us portable, light, and udeful.

Second, and building on that, you add a tremendous amount of overhead to
every call. Writing to a database, actually checking the database
schema, and all the problems you incur with this behavior make JDOM a
heavyweight API in this case.

Third, you abandon all portability. I should be able to build a JDOM
Document from any input form, manipulate it in the same fashion, and
output it to any supported output form. This ability to move from one
input (SAX, DOM, JDOM, RDBMS) to the /same/ internal representation, to
any other output format (SAX, DOM, JDOM, RDBMS) and chaining the calls
is what, IMO, makes JDOM really cool.

While certainly you can do what you are wanting (it is open-source!),
I'm suggesting that you not, and rethink your decision; adding input and
output from a database is something I'd like to see, but adding
automatic committal, etc., isn't something I would endorse or want to
encourage users to do (i.e. by putting it in jdom-contrib). Think it
over, and I think you'll see that input and output are better ideas.

-Brett

> --
> 
> Gerardo Horvilleur
> mago@mail.internet.com.mx
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org

From aidan at concordianet.com  Tue Sep  5 03:28:19 2000
From: aidan at concordianet.com (Aidan Killian)
Date: Fri Aug  6 17:04:47 2004
Subject: [jdom-interest] Re: Finding the DTD
References: <200009050607.AAA01261@dorothy.denveronline.net>
Message-ID: <39B4CAC3.F39AEC69@concordianet.com>

Hi,

	I have a slightly more complex version of this problem.
Typically I recieve XML files with the following DOCTYPE 
statement:

<!DOCTYPE FpML PUBLIC "-//FpML//DTD Financial product Markup Language
(1-0))//EN">

	A System Identifier string ("FpML-1.0.dtd") may follow the public
identifier. This is quite a common situation in the SGML world that is
addressed by the Oasis Open Catalog standard.

	When using Xerces I use the EntityResolver interface:

public class Catalog implements EntityResolver 
{
	public InputSource resolveEntity (String publicId, String systemId)
	{
		// ...

		return new InputSource(new FileReader(DTDpath));
	}
}

	I do not believe the build(InputStream, String) method solves 
this problem. (B.T.W. I only know how to implement this in Xerces and
XML4J 1.x; I am not sure if other parsers even support entity mapping).

	Great work; I really like JDOM.

Best regards,
	Aidan Killian (ConcordiaNet Inc.)

> Message: 10
> Date: Mon, 04 Sep 2000 22:50:01 +0200
> From: Jason Hunter <jhunter@collab.net>
> To: "Muhle, Daniel" <Daniel.Muhle@mettenmeier.de>
> CC: "'jdom-interest@jdom.org'" <jdom-interest@jdom.org>
> Subject: Re: [jdom-interest] Finding the DTD
> 
> >       SAXBuilder builder = new SAXBuilder();
> >       Document doc =  builder.build(in);
> >
> >  I get an FileNotFoundException, because the parser tries to
> > find the DTD in a directory relative to
> > the directory, the Webserver is started from.
> 
> That's why there's a build(InputStream, String) method.
>

From guyn at tantian.com  Tue Sep  5 04:56:00 2000
From: guyn at tantian.com (Guy Nirpaz)
Date: Fri Aug  6 17:04:47 2004
Subject: [jdom-interest] Convert XML data to Java ojbects
Message-ID: <00f001c01730$43b99a00$080aa8c0@tantian.local>

> >
> > You need to give us more information; it's very fuzzy what you are
> > doing. I think I know, but I doubt the rest of the list does. Post your
> > configuration file (or an example), your use-case for doing this, and
> > some detail about what the result is. Then we can talk on it further.
> >
 Sorry if I wasn't clear, it seems so obvious to me :-)

 The mechanism can be viewed as a combination of :

 JavaOutputter and ObjectBuilder (currently the names are different)

 The JavaOutputter - takes a Java instance and output it to XML document -
or element
 The ObjectBuilder - intantiates a Java instance out of XML element

 for example -
 <code>
 public class Person {

      private String firstName = null ;
      private String lastName = null ;
      private Address address = null ;
 }
 </code>

 with getXXX methods for properties is converted by default to -

 <?xml version="1.0" encoding="UTF-8"?>
 <person>
      <firstName>Michael</firstName>
      <lastName>Jordan</lastName>
      <address>
           <street>Bulls court</street>
           <houseNumber>100</houseNumber>
           <state>IL</state>
           <country>United Stated</country>
      </address>
 </person>

 This direction eliminates the need to code conversion to XML for every
class
 that can be described that way. For example - I use it to convert
 EntityBeans to XML representation. By that the client application isn't
 aware of the data actuall representation.

 The other direction is supported as well.
 The exact XML doc above can instatiate a 'live' instance of Person class.

 Hope I was more clear now,

 Guy



From EGalluzzo at synchrony.net  Tue Sep  5 06:57:08 2000
From: EGalluzzo at synchrony.net (Galluzzo, Eric)
Date: Fri Aug  6 17:04:47 2004
Subject: [jdom-interest] API instability?
Message-ID: <51C6625F6F63D211853B0008C74C1A1EFA77A6@corp-exchg-001.synchrony.net>

> -----Original Message-----
> From: Elliotte Rusty Harold [mailto:elharo@metalab.unc.edu]
> 
> >When you say parent.getChild("child") it's kinda natural for the
> >unspecified namespace of "child" to be the same as the 
> parent, not the
> >no-namespace.  It's a simple way of thinking: ask Bob Jones about his
> >kid Billy and he naturally refers to the Billy in the Jones 
> namespace.
> >:-)
> >
> 
> Bugs or no bugs, this just doesn't seem obvious to me. I'd rather 
> explicitly specify my namespaces. I think this is going to cause big, 
> unexpected problems for programmers when they encounter documents 
> where the children don't have the same namespaces as the parent.

Well, I can't see how this is different from the current situation.  If a
child has a different namespace from its parent, its namespace must be
specified during getChild(), in both the current and the proposed new
implementation.  The only difference would be if you had an element in the
default namespace underneath one in some other namespace, which is fairly
rare.  In fact, the only place I've ever seen this is in an XSLT stylesheet.

In fact, the whole reason I proposed getChild() retrieve elements of the
same namespace by default is that that is the behavior I expected from that
method, and it seems to me to be a much more useful behavior.  I agree that
there are cases wherein one wishes to retrieve children in different
namespaces from their parents, but this is easily accomplished in the same
way that it currently is.  In addition, it is much more common (in my
experience) to want to retrieve children in the same namespace, and this
proposed change would make it considerably easier for this to happen.

    - Eric

From EGalluzzo at synchrony.net  Tue Sep  5 07:02:59 2000
From: EGalluzzo at synchrony.net (Galluzzo, Eric)
Date: Fri Aug  6 17:04:47 2004
Subject: [jdom-interest] API instability?
Message-ID: <51C6625F6F63D211853B0008C74C1A1EFA77A7@corp-exchg-001.synchrony.net>

Hmmm.  This is indeed a problem, and I can't think of a wonderful solution
for it.  I'd be willing to live with this (since I assume one would not want
to change addContent() to alter the child's namespace!), but others may not.
Vote? :)

Also, the second version of the code below would continue to work.

    - Eric

> -----Original Message-----
> From: Jason Hunter [mailto:jhunter@collab.net]
> Sent: Sunday, September 03, 2000 4:26 PM
> To: Elliotte Rusty Harold
> Cc: Brett McLaughlin; Galluzzo Eric; 'jdom-interest@jdom.org'
> Subject: Re: [jdom-interest] API instability?
> 
> To argue against myself and with Elliotte, another problem with
> getChild("child") using the parent's namespace is that
> 
> Element kid = new Element("kid");
> parent.addContent(kid);
> parent.getChild("kid");
> 
> *wouldn't work* if the parent was in a namespace.  That's pretty
> confusing.  With the current code it would work because kid 
> would be in
> no namespace.  With namespaces it'd work too:
> 
> Element kid = new Element("kid", ns);
> parent.addContent(kid);
> parent.getChild("kid", ns);

From sclark at e-numerate.com  Tue Sep  5 07:26:36 2000
From: sclark at e-numerate.com (Clark, Stacie)
Date: Fri Aug  6 17:04:47 2004
Subject: [jdom-interest] Javadocs
Message-ID: <878F521262E9D31184FF00C0F047DEEE073490@MAIL>

Jason,
  I looked at the XML file that is the basis for building with Ant (I have
not been familiar with Ant, though clearly that must change :-) and of
course using "build javadoc" is the correct solution.  Since several people
had asked about javadoc, and no one had mentioned that the XML file
supported this build, I assumed that the build file didn't support javadoc
and we had to "roll our own." Sorry to have wasted everyone's time.

> -----Original Message-----
> From: Jason Hunter [mailto:jhunter@collab.net]
> Sent: Saturday, September 02, 2000 10:50 PM
> To: sclark@e-numerate.com; jdom interest
> Subject: Re: [jdom-interest] Javadocs
> 
> 
> > I realize that the official project JavaDocs will not be 
> built until 
> > beta5. Rather, I was suggesting that some users might prefer to 
> > build their own Javadocs in the interim. 
> 
> What's wrong with "build javadoc"?  It's a standard build target we've
> had since the beginning.
> 
> -jh-
> 
> 

From brett.mclaughlin at lutris.com  Tue Sep  5 07:33:53 2000
From: brett.mclaughlin at lutris.com (Brett McLaughlin)
Date: Fri Aug  6 17:04:47 2004
Subject: [jdom-interest] Convert XML data to Java ojbects
References: <00f001c01730$43b99a00$080aa8c0@tantian.local>
Message-ID: <39B50451.9FF7F001@lutris.com>


Guy Nirpaz wrote:
> 
> > >
> > > You need to give us more information; it's very fuzzy what you are
> > > doing. I think I know, but I doubt the rest of the list does. Post your
> > > configuration file (or an example), your use-case for doing this, and
> > > some detail about what the result is. Then we can talk on it further.
> > >
>  Sorry if I wasn't clear, it seems so obvious to me :-)
> 
>  The mechanism can be viewed as a combination of :
> 
>  JavaOutputter and ObjectBuilder (currently the names are different)
> 
>  The JavaOutputter - takes a Java instance and output it to XML document -
> or element
>  The ObjectBuilder - intantiates a Java instance out of XML element
> 
>  for example -
>  <code>
>  public class Person {
> 
>       private String firstName = null ;
>       private String lastName = null ;
>       private Address address = null ;
>  }
>  </code>
> 
>  with getXXX methods for properties is converted by default to -
> 
>  <?xml version="1.0" encoding="UTF-8"?>
>  <person>
>       <firstName>Michael</firstName>
>       <lastName>Jordan</lastName>
>       <address>
>            <street>Bulls court</street>
>            <houseNumber>100</houseNumber>
>            <state>IL</state>
>            <country>United Stated</country>
>       </address>
>  </person>
> 
>  This direction eliminates the need to code conversion to XML for every
> class
>  that can be described that way. For example - I use it to convert
>  EntityBeans to XML representation. By that the client application isn't
>  aware of the data actuall representation.
> 
>  The other direction is supported as well.
>  The exact XML doc above can instatiate a 'live' instance of Person class.

OK. Makes sense. Now could you explain (to others) why you would use
your methodology instead of data binding? Data Binding would create the
Person class for you, create the Address class for you, and then using a
Marshaller and Unmarshaller, convert back and forth. There wouldn't be a
need for this, if you used data binding... let us know what use case
this fills that a more standard methodoogy doesn't.

-Brett

p.s. There are good reasons for this, but I want to work through them
;-)

> 
>  Hope I was more clear now,
> 
>  Guy
> 
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org

From dsmiley at mitre.org  Tue Sep  5 07:38:28 2000
From: dsmiley at mitre.org (David W. Smiley)
Date: Fri Aug  6 17:04:47 2004
Subject: [jdom-interest] API instability?
References: <200009040522.XAA24590@dorothy.denveronline.net>
Message-ID: <39B50564.E2E511AE@mitre.org>

> To argue against myself and with Elliotte, another problem with
> getChild("child") using the parent's namespace is that
> 
> Element kid = new Element("kid");
> parent.addContent(kid);
> parent.getChild("kid");
> 
> *wouldn't work* if the parent was in a namespace.

	Given the way I propose things should work (I sent a long email to the
list Friday), that *will work*.  If you ask for a child without
specifying a namespace, you get a child with that name regardless of
namespace (unless you use the getChild that specifies a particular
namespace).  I would recommend that people usually specify a namespace
when getting a child in case the document was adorned with elements not
in the namespace that your application is concerned with.  I think
clients in general have a particular namespace in mind.

-- David Smiley


From brett.mclaughlin at lutris.com  Tue Sep  5 07:40:12 2000
From: brett.mclaughlin at lutris.com (Brett McLaughlin)
Date: Fri Aug  6 17:04:47 2004
Subject: [jdom-interest] Re: Finding the DTD
References: <200009050607.AAA01261@dorothy.denveronline.net> <39B4CAC3.F39AEC69@concordianet.com>
Message-ID: <39B505CC.CBA33F2A@lutris.com>


Aidan Killian wrote:
> 
> Hi,
> 
>         I have a slightly more complex version of this problem.
> Typically I recieve XML files with the following DOCTYPE
> statement:
> 
> <!DOCTYPE FpML PUBLIC "-//FpML//DTD Financial product Markup Language
> (1-0))//EN">
> 
>         A System Identifier string ("FpML-1.0.dtd") may follow the public
> identifier. This is quite a common situation in the SGML world that is
> addressed by the Oasis Open Catalog standard.
> 
>         When using Xerces I use the EntityResolver interface:
> 
> public class Catalog implements EntityResolver
> {
>         public InputSource resolveEntity (String publicId, String systemId)
>         {
>                 // ...
> 
>                 return new InputSource(new FileReader(DTDpath));
>         }
> }
> 
>         I do not believe the build(InputStream, String) method solves
> this problem. (B.T.W. I only know how to implement this in Xerces and
> XML4J 1.x; I am not sure if other parsers even support entity mapping).
> 
>         Great work; I really like JDOM.

There is now a setEntityResolver() method on SAXBuilder where you can do
exactly what you mention above. That will work for you, correct? It's in
the latest CVS version.

-Brett

> 
> Best regards,
>         Aidan Killian (ConcordiaNet Inc.)
> 
> > Message: 10
> > Date: Mon, 04 Sep 2000 22:50:01 +0200
> > From: Jason Hunter <jhunter@collab.net>
> > To: "Muhle, Daniel" <Daniel.Muhle@mettenmeier.de>
> > CC: "'jdom-interest@jdom.org'" <jdom-interest@jdom.org>
> > Subject: Re: [jdom-interest] Finding the DTD
> >
> > >       SAXBuilder builder = new SAXBuilder();
> > >       Document doc =  builder.build(in);
> > >
> > >  I get an FileNotFoundException, because the parser tries to
> > > find the DTD in a directory relative to
> > > the directory, the Webserver is started from.
> >
> > That's why there's a build(InputStream, String) method.
> >
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org

From brett.mclaughlin at lutris.com  Tue Sep  5 07:46:33 2000
From: brett.mclaughlin at lutris.com (Brett McLaughlin)
Date: Fri Aug  6 17:04:47 2004
Subject: [jdom-interest] DOMBuilder update
Message-ID: <39B50749.3F2A4C@lutris.com>

Thanks to Yusuf Goolamabbas, a small, but handy, patch was just checked
into CVS. DOMBuilder now allows a JDOM Element to be built from a DOM
Element. So you can do:

DOMBuilder builder = new DOMBuilder();
org.jdom.Element element = builder.build(myDOMElement);

where myDOMElement is of type org.w3c.dom.Element.

Cool, huh?

-Brett

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org

From brett.mclaughlin at lutris.com  Tue Sep  5 07:52:49 2000
From: brett.mclaughlin at lutris.com (Brett McLaughlin)
Date: Fri Aug  6 17:04:47 2004
Subject: [jdom-interest] XMLOutputter error escaping this:   
 element.addContent("");
References: <4.3.2.7.2.20000902150151.023efd00@mail.posttool.com>
Message-ID: <39B508C1.A9EADA55@lutris.com>

Just went into CVS... check it out and let me know if it works!

-Brett

Beau Bisquette wrote:
> 
> Dear Brett,
> 
> We have been experiencing difficulty outputting XML which has elements with
> empty content- not a new element with no content, but an element with ""
> content.
>         ie: element.addContent("");
> 
> so we propose this fix (or a more elegant rewrite...) starting at line 513
> of XMLOutputter,java
> 
> // Print the tag  with String on same line
> // Example: tag name="value">content/tag>
> // ** blows up if "" has been added as content to any element
> // ** so we must test for funkiness.
> // ** (david@posttool.com, will@posttool.com) String elementText =
> element.getText();
> if ( ( elementText != null ) && !( elementText.equals( "" ) ) ) {
>         out.write(">");
>         out.write(escapeElementEntities(elementText));
>         out.write("/");
>         out.write(element.getQualifiedName());
>         out.write(">");
> } else {
>         out.write(" />");
> }
> // end of test...
> 
> Thanks,
> David & Will
> 
> Beau Bisquette
> TPC Productions
> Oakland, California
> 
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org

From jpeck at stshotelnet.com  Tue Sep  5 07:16:26 2000
From: jpeck at stshotelnet.com (Jason Peck)
Date: Fri Aug  6 17:04:47 2004
Subject: [jdom-interest] 1.0 Release Date
Message-ID: <000301c01743$e1261170$8e02010a@stsws143>

Is there an expected release date for 1.0?  I looked through the archives to
see if I could find one but was unsuccessful.  I have been using the latest
builds for about 2 weeks now and want to propose it as a standard for our
development project.  But as usual, my manager wants to make sure it will be
released by our go live date or sooner.  A rough guesstimate would work...


From Brad.Morgan at e-pubcorp.com  Tue Sep  5 08:49:02 2000
From: Brad.Morgan at e-pubcorp.com (Brad Morgan)
Date: Fri Aug  6 17:04:47 2004
Subject: [jdom-interest] Changes
In-Reply-To: <39B412B9.5949ECE@lutris.com>
Message-ID: <NDBBLFGNKKGCBIJEAIJBEELKCGAA.Brad.Morgan@e-pubcorp.com>

According to the web page, http://cvs.jdom.org/cgi-bin/viewcvs.cgi/, a
complete
source archive is supposedly generated once every 24 hours.

I am behind a firewall and the command line cvs command doesn't work for me,
but
the above archive should be sufficient if its working.

I just copied the latest version and the date of the newest file in the
archive is  8/8/00.

Is this archiving procedure working?

Brad Morgan
e-Publishing Corp.

Email: Brad.Morgan@e-pubcorp.com
Phone: (719)593-7377 x35
Fax: (719)593-2996

e-Publishing Corp. is a BroadVision company
NOTICE: This message is intended only for the use of the Addressee and may
contain information that is PRIVILEGED and CONFIDENTIAL. If you are not the
intended recipient, dissemination of this communication is prohibited. If
you have received this communication in error, please erase all copies of
the message and its attachments and notify us immediately.



-----Original Message-----
From: jdom-interest-admin@jdom.org
[mailto:jdom-interest-admin@jdom.org]On Behalf Of Brett McLaughlin
Sent: Monday, September 04, 2000 3:23 PM
To: jdom-interest@jdom.org
Subject: [jdom-interest] Changes


All-

  I just made some additional changes/etc. to the JDOM tree.

* Implemented Elliotte's changes to XMLOutputter and Namespace to handle
more advanced prefix/URI mappings
* Added debugging into SAXBuidler (commented out) so I can check on the
Xerces bug with inline DOCTYPE declarations
* Updated xerces.jar to Xerces 1.2.0
* Updated TODO.txt

Please update your tree and check it all out... thanks!

-Brett

--
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc.
1200 Pacific Avenue, Suite 300
Santa Cruz, CA 95060 USA
http://www.lutris.com
http://www.enhydra.org
_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com


From jhunter at collab.net  Tue Sep  5 10:03:55 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:04:47 2004
Subject: [jdom-interest] Javadocs
References: <878F521262E9D31184FF00C0F047DEEE073490@MAIL>
Message-ID: <39B5277B.DDFEE0E5@collab.net>

> Since several people
> had asked about javadoc, and no one had mentioned that the XML file
> supported this build, I assumed that the build file didn't support 
> javadoc and we had to "roll our own." 

It's mentioned in the README.txt, and hopefully that's what people read
first.  (If you have beta4, it wasn't in that README.)

-jh-

From aidan at concordianet.com  Tue Sep  5 11:52:16 2000
From: aidan at concordianet.com (Aidan Killian)
Date: Fri Aug  6 17:04:47 2004
Subject: [jdom-interest] Re: Finding the DTD 
Message-ID: <39B540E0.B462D905@concordianet.com>

> 
> There is now a setEntityResolver() method on SAXBuilder where you can do
> exactly what you mention above. That will work for you, correct? It's in
> the latest CVS version.
> 

Thanks Brett,

	that sounds just like what I need. I will try to 
get the latest CVS copy first thing in the morning (UK 
time).

Best regards,
	Aidan Killian

From EMorehouse at fool.com  Tue Sep  5 12:02:04 2000
From: EMorehouse at fool.com (Ed Morehouse)
Date: Fri Aug  6 17:04:47 2004
Subject: [jdom-interest] Re: accessing Element.getChildren() elements with a ListIterator
Message-ID: <39B5432C.B86396C6@fool.com>

For those who asked why the ListIterator didn't work:

The set(Object) method seems to have no effect at all.  I see from the Java2
docs that this is an optional method, so i'm guessing it's not implemented in
the default ListIterator for LinkedList.  If this is the case, then perhaps (as
Jason suggested) we need to override listIterator() in PartialList and then
write a PartialListIterator class that implements ListIterator and all of its
methods.

Since the current philosophy for accessing an Element's children seems to be
through the List interface, and the current implementation of that List is a
LinkedList, it seems relatively important to have a way to do sequential access
and modification to child elements without having to start at the first index
and walk our way down what may in some cases be a very long chain each time we
want the next child.

That said, i'm not yet very familiar with the jdom source tree so if i'm missing
something, someone please do set me straight.  So...what do people think, do we
need a PartialListIterator, should PartialList be implemented using a different
AbstractList (a Vector, perhaps), or am i misunderstanding the situation and
need to be set straight?

-Ed


earlier I wrote:
> 
> I am also somewhat new around here and somewhat confused by the way to access an
> Element's children.
> 
> I have a case where I want to recurse my way through an Element tree, examine
> each node, test for a given condition, and possibly replace the Element at that
> node with a different one, based on the results of the test.
> 
> The following code fragment seems to work for me:
> 
>   protected Element processElementTree(Element element)
>     throws Exception
>   {
>     if (element.getName().equals("reference"))
>     {
>       // we need to dereference this element:
>       element = dereference(element);
>     }
>     else if (element.getChildren().size() > 0)
>     {
>       // this element has children so we need to recurse:
>       List children = element.getChildren();
>       for (int i = 0; i < children.size(); i++)
>       {
>         children.set(i, processElementTree((Element)children.get(i)));
>       }
>     }
>     else
>     {
>       // this element is a leaf node and is not a reference
>       // so leave it alone
>     }
>     return element;
>   }
> 
> However, I see that org.jdom.PartialList extends java.util.LinkedList, which
> means that accessing later elements grows increasingly expensive.  Thus, I would
> like to use a ListIterator to access the children, which should provide
> sequential access at constant cost:
> 
>   protected Element processElementTree(Element element)
>     throws Exception
>   {
>     if (element.getName().equals("reference"))
>     {
>       // we need to dereference this element:
>       element = dereference(element);
>     }
>     else if (element.getChildren().size() > 0)
>     {
>       // this element has children so we need to recurse:
>       ListIterator childIterator = element.getChildren().listIterator();
>       while (childIterator.hasNext())
>       {
>         Element child = (Element)childIterator.next();
>         childIterator.set(processElementTree(child));
>       }
>     }
>     else
>     {
>       // this element is a leaf node and is not a reference
>       // so leave it alone
>     }
>     return element;
>   }
> 
> I suppose i could do a toArray() on the List or something, but I thought that
> the reason for the List in the first place was so that you could do List style
> things to it.
> 
> Could someone please explain why the ListIterator approach doesn't work; if the
> fact that it doesn't work is a design decision, the basis for that decision; and
> if there are elegant alternative ways of doing this that I am missing, what
> those might be.

                                  ------------
 
 - The happiest of people aren't the ones 
   who always have the best of everything;
   they are the ones who always make the best 
   of everything they have.

                                           Ed Morehouse
                                           Software Engineer/Evil Genius
                                           The Motley Fool

From brett.mclaughlin at lutris.com  Tue Sep  5 12:28:24 2000
From: brett.mclaughlin at lutris.com (Brett McLaughlin)
Date: Fri Aug  6 17:04:47 2004
Subject: [jdom-interest] CDATA support
Message-ID: <39B54958.EB93324F@lutris.com>

All-

  Thanks to the great work of Dan Schaffer, and gentle and not so gentle
reminders from him and Kevin Regan over the months, JDOM now has full
support for CDATA. Yup, it's in there, and will be part of Beta 5. Check
out CVS. It involved adding a new class, org.jdom.CDATA, as well as
changes to DOMBuilder, SAXBuilder, XMLOutputter, and DOMOutputter. So it
works for DOM structures as well as the normal means of handling JDOM.

There is a sample in samples/ called cdata.xml - run 

build clean
build
build samples

and then you can run SAXBuilderDemo on samples/cdata.xml and see the
CDATA section work.

Very cool - kudos to Dan for keeping this going, and making mods when I
changed CVS all over this weekend ;-)

Thanks,
Brett

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org

From rodney.sonderegger at incaparc.ch  Tue Sep  5 11:20:07 2000
From: rodney.sonderegger at incaparc.ch (Rodney Sonderegger)
Date: Fri Aug  6 17:04:47 2004
Subject: [jdom-interest] Accessing Child Elements
Message-ID: <39B53957.A6403603@incaparc.ch>

Hello

we're testing JDOM in our application and I found some strange things,
which I can't explain.
I'm using the SAXBuilder to read the Streamdata passed by the Database
(Tamino):
-------------------------------------------------------------------
  <?xml version="1.0" encoding="utf-8" ?>
 <ino:response
xmlns:ino="http://namespaces.softwareag.com/tamino/response2"
xmlns:xql="http://metalab.unc.edu/xql/">
  <xql:query>Profile[ProviderKey="0011" and
Application="eRetail"]</xql:query>
 <ino:message ino:returnvalue="0">
  <ino:messageline>XQL Request processing</ino:messageline>
  </ino:message>
 <xql:result>
 <Profile ino:id="2">
  <Application>eRetail</Application>
  <ProviderKey>0011</ProviderKey>
  <DefaultLanguage>de</DefaultLanguage>
  <DefaultPriority>1</DefaultPriority>
  <URLPrefix>www.yellowgate.ch/cgi-bin/ygate/yellowgate</URLPrefix>
  <InfoKeySequence>5</InfoKeySequence>
  </Profile>
  </xql:result>
 <ino:cursor ino:count="1">
  <ino:first ino:href="?_XQL(1,16)=Profile[ProviderKey="0011" and
Application="eRetail"]" />
  </ino:cursor>
 <ino:message ino:returnvalue="0">
  <ino:messageline>XQL Request processed</ino:messageline>
  </ino:message>
  </ino:response>
----------------------------


The Parser works fine and parses the document without errors.
I'm interested in the <Profile> Element and try to get it with:

      Element root = aDoc.getRootElement();
      Element xmlProfile = root.getChild("result").getChild("Profile");

I get an NULL Pointerexception trying to do that.
when I  run an Iterator:

    Iterator anIt = root.getChildren().iterator();
      while (anIt.hasNext()){
        Element aElem = (Element) anIt.next();
        if (aElem.getName().equals("result")){
          xmlProfile = aElem;
          ......
        }
      }

then I can access the subelements of <result> does anybody know why this

is the case??

Thanx & Regards
Rodney

From veerpal at hotbot.com  Tue Sep  5 07:32:01 2000
From: veerpal at hotbot.com (veerpal singh)
Date: Fri Aug  6 17:04:47 2004
Subject: [jdom-interest] ID and IDREF
Message-ID: <MFBHCBDKCDCJBAAA@hotbot.com>

Hi All

I was just looking around on net for ID and IDREF processing. Is it possible thru jdom that when idref is encountered, element having iD can be retrieved. Or has to be done by higher level appl.

Thanks
VS



HotBot - Search smarter.
http://www.hotbot.com

From jhunter at collab.net  Tue Sep  5 14:33:48 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:04:47 2004
Subject: [jdom-interest] 1.0 Release Date
References: <000301c01743$e1261170$8e02010a@stsws143>
Message-ID: <39B566BC.901F9621@collab.net>

Jason Peck wrote:
> 
> Is there an expected release date for 1.0? 

We'll release when we're ready to freeze the API and believe we have a
solid implementation.  We're all volunteers working in our spare time,
so predicting when that will happen isn't something I want to do.  I'd
be comfortable using JDOM in production now, since the code's pretty
solid.  Just test it thoroughly.  As you'll notice, most traffic on the
list is about enhancing the design and not bug fixing.  The TODO.txt
file lists the outstanding work items.

-jh-

From cfoley at chipdata.com  Tue Sep  5 14:54:36 2000
From: cfoley at chipdata.com (Cash Foley)
Date: Fri Aug  6 17:04:47 2004
Subject: [jdom-interest] Exception: getRawName(I)Ljava/lang/String; not found
Message-ID: <AGELJKBOOOMHOEGMPKMCKEOLCBAA.cfoley@chipdata.com>

All -

I'm sorry if this is a dumb question (it's likely because I'm fairly new to
java) and I thank you for any help in advance.

I grabbed the 'SAXBuilderDemo.java' code

Removed:

package org.jdom.examples;

and built it under 'MySAXBuilderDemo'

When I ran it I got the following exception:

Exception in thread "main" java.lang.NoSuchMethodError:
org.xml.sax.Attributes: method getRawName(I)Ljava/lang/String; not found
        at org.jdom.input.SaxHandler.startElement(SAXBuilder.java, Compiled
Code)
        at org.apache.xerces.parsers.SAXParser.startElement(SAXParser.java,
Compiled Code)
        at
org.apache.xerces.validators.common.XMLValidator.callStartElement(XMLValidat
or.java, Compiled Code)
        at
org.apache.xerces.framework.XMLDocumentScanner.scanElement(XMLDocumentScanne
r.java, Compiled Code)
        at
org.apache.xerces.framework.XMLDocumentScanner$ContentDispatcher.dispatch(XM
LDocumentScanner.java, Compiled Code)
        at
org.apache.xerces.framework.XMLDocumentScanner.parseSome(XMLDocumentScanner.
java, Compiled Code)
        at org.apache.xerces.framework.XMLParser.parse(XMLParser.java:861)
        at org.jdom.input.SAXBuilder.build(SAXBuilder.java:207)
        at org.jdom.input.AbstractBuilder.build(AbstractBuilder.java:95)
        at MySAXBuilderDemo.testBuilder(MySAXBuilderDemo.java:101)
        at MySAXBuilderDemo.main(MySAXBuilderDemo.java:138)


Any help?

Thanks

Cash Foley

cfoley@chipdata.com
--
**********************************************************************
** ChipData, Inc.                           http://www.chipdata.com **
** 959 E. Collins Blvd Suite 123                                    **
** Richardson, TX 75081                                972-739-5327 **
**********************************************************************




From jstratton at telegea.com  Tue Sep  5 14:58:38 2000
From: jstratton at telegea.com (Stratton, Jason)
Date: Fri Aug  6 17:04:47 2004
Subject: [jdom-interest] Servlet sample
Message-ID: <AB72DC50CB6AD3119A6A00902798A0227E1B9D@EXCHANGE>

Sorry to pester the list with something that appears somewhat trivial, but I
have to get a proof of concept done ASAP and I did not find a sample archive
and I figured the people on this list cumulatively must have done this
hundreds of times over.

Could anyone furnish a sample servlet that takes an XML string in the body
of a post and parses it? It does not have to do anything interesting with
it. All I'm looking to do is traverse the doc and modify and attribute and
add an element or two then send the XML back. I believe there are plenty of
examples of this in the mailing list archives.

Also, if someone could direct me to some notes on how to install and build
the source, that would be great. I know there is a build.bat to do the
actual build on Windows, but do the sources need to be unzipped anywhere in
particular? Build.bat depends on ant. Do I need to download ant? There is a
xerces.jar in the zip. Should I download the most recent and should it be
put anywhere in particular as well?


I apologize again for wasting your bandwidth with this, but I'm a newbie
with a deadline. :)
Thank you.
Jason

From pvg at c-c-s.com  Tue Sep  5 15:07:26 2000
From: pvg at c-c-s.com (Peter V. Gadjokov)
Date: Fri Aug  6 17:04:47 2004
Subject: [jdom-interest] Accessing Child Elements
Message-ID: <704ECFDA88B3D311B5F000A0C959E5B601FBB8@adobo.c2labs.com>

 
Element.getChild(String name) assumes you are looking for an element in
the 'empty' namespace and your "result" element belongs to the
xql-prefixed namespace. You get null back and your next chained method
call dies trying to dereference the receiver (null).

This brings an API comment to mind - when namespaces are used, 
getChild(String elemName) becomes quite useless and it's behaviour is
arguably not entirely intuitive. If the implementation were changed to:

public Element getChild(String name)
{
    return getChild(name, namespace); // use the enclosing namespace
}

the behaviour in the for the no-namespaces-used remains the same as it
is now and something more sensible is returned when namespaces are in
use.  The pathological case (wanting specifically the empty namespace in
a document with namespace use) is still supported by the more general
api call, the simple call does something that seems more intuitive (to
me, at least). Of course, that still would not have helped Herr
Sonderegger since the root and the immediate child are in different
namespaces but 

result = root.getChild("result", XQL_NAMESPACE);
profile = result.getChild("Profile"); 

would have worked as expected. 

-pvg

None of this 
-----Original Message-----
From: Rodney Sonderegger
To: jdom-interest@jdom.org
Sent: 9/5/00 11:20 AM
Subject: [jdom-interest] Accessing Child Elements

Hello

we're testing JDOM in our application and I found some strange things,
which I can't explain.
I'm using the SAXBuilder to read the Streamdata passed by the Database
(Tamino):
-------------------------------------------------------------------
  <?xml version="1.0" encoding="utf-8" ?>
 <ino:response
xmlns:ino="http://namespaces.softwareag.com/tamino/response2"
xmlns:xql="http://metalab.unc.edu/xql/">
  <xql:query>Profile[ProviderKey="0011" and
Application="eRetail"]</xql:query>
 <ino:message ino:returnvalue="0">
  <ino:messageline>XQL Request processing</ino:messageline>
  </ino:message>
 <xql:result>
 <Profile ino:id="2">
  <Application>eRetail</Application>
  <ProviderKey>0011</ProviderKey>
  <DefaultLanguage>de</DefaultLanguage>
  <DefaultPriority>1</DefaultPriority>
  <URLPrefix>www.yellowgate.ch/cgi-bin/ygate/yellowgate</URLPrefix>
  <InfoKeySequence>5</InfoKeySequence>
  </Profile>
  </xql:result>
 <ino:cursor ino:count="1">
  <ino:first ino:href="?_XQL(1,16)=Profile[ProviderKey="0011" and
Application="eRetail"]" />
  </ino:cursor>
 <ino:message ino:returnvalue="0">
  <ino:messageline>XQL Request processed</ino:messageline>
  </ino:message>
  </ino:response>
----------------------------


The Parser works fine and parses the document without errors.
I'm interested in the <Profile> Element and try to get it with:

      Element root = aDoc.getRootElement();
      Element xmlProfile = root.getChild("result").getChild("Profile");

I get an NULL Pointerexception trying to do that.
when I  run an Iterator:

    Iterator anIt = root.getChildren().iterator();
      while (anIt.hasNext()){
        Element aElem = (Element) anIt.next();
        if (aElem.getName().equals("result")){
          xmlProfile = aElem;
          ......
        }
      }

then I can access the subelements of <result> does anybody know why this

is the case??

Thanx & Regards
Rodney
_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@you
rhost.com

From jhunter at collab.net  Tue Sep  5 14:56:59 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:04:47 2004
Subject: [jdom-interest] Servlet sample
References: <AB72DC50CB6AD3119A6A00902798A0227E1B9D@EXCHANGE>
Message-ID: <39B56C2B.3DED786@collab.net>

> Could anyone furnish a sample servlet that takes an XML string in 
> the body of a post and parses it? 

Use the normal SAXBuilder but use req.getInputStream() as the input
stream.

> All I'm looking to do is traverse the doc and modify and attribute and
> add an element or two then send the XML back. 

Use the normal XMLOutputter but pass res.getWriter() as the writer.

-jh-

From brett.mclaughlin at lutris.com  Tue Sep  5 16:02:43 2000
From: brett.mclaughlin at lutris.com (Brett McLaughlin)
Date: Fri Aug  6 17:04:47 2004
Subject: [jdom-interest] Exception: getRawName(I)Ljava/lang/String; not found
References: <AGELJKBOOOMHOEGMPKMCKEOLCBAA.cfoley@chipdata.com>
Message-ID: <39B57B93.446CB401@lutris.com>


Cash Foley wrote:
> 
> All -
> 
> I'm sorry if this is a dumb question (it's likely because I'm fairly new to
> java) and I thank you for any help in advance.
> 
> I grabbed the 'SAXBuilderDemo.java' code
> 
> Removed:
> 
> package org.jdom.examples;
> 
> and built it under 'MySAXBuilderDemo'
> 
> When I ran it I got the following exception:
> 
> Exception in thread "main" java.lang.NoSuchMethodError:
> org.xml.sax.Attributes: method getRawName(I)Ljava/lang/String; not found
>         at org.jdom.input.SaxHandler.startElement(SAXBuilder.java, Compiled
> Code)
>         at org.apache.xerces.parsers.SAXParser.startElement(SAXParser.java,
> Compiled Code)
>         at
> org.apache.xerces.validators.common.XMLValidator.callStartElement(XMLValidat
> or.java, Compiled Code)
>         at
> org.apache.xerces.framework.XMLDocumentScanner.scanElement(XMLDocumentScanne
> r.java, Compiled Code)
>         at
> org.apache.xerces.framework.XMLDocumentScanner$ContentDispatcher.dispatch(XM
> LDocumentScanner.java, Compiled Code)
>         at
> org.apache.xerces.framework.XMLDocumentScanner.parseSome(XMLDocumentScanner.
> java, Compiled Code)
>         at org.apache.xerces.framework.XMLParser.parse(XMLParser.java:861)
>         at org.jdom.input.SAXBuilder.build(SAXBuilder.java:207)
>         at org.jdom.input.AbstractBuilder.build(AbstractBuilder.java:95)
>         at MySAXBuilderDemo.testBuilder(MySAXBuilderDemo.java:101)
>         at MySAXBuilderDemo.main(MySAXBuilderDemo.java:138)
> 
> Any help?

You have either a really old version of Xerces, or a really old version
of JDOM.

Get the latest version from CVS of JDOM and use that and the xerces.jar
in the lib/ directory it comes with. It should work fine, then.

-Brett

> 
> Thanks
> 
> Cash Foley
> 
> cfoley@chipdata.com
> --
> **********************************************************************
> ** ChipData, Inc.                           http://www.chipdata.com **
> ** 959 E. Collins Blvd Suite 123                                    **
> ** Richardson, TX 75081                                972-739-5327 **
> **********************************************************************
> 
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org

From brett.mclaughlin at lutris.com  Tue Sep  5 16:07:25 2000
From: brett.mclaughlin at lutris.com (Brett McLaughlin)
Date: Fri Aug  6 17:04:47 2004
Subject: [jdom-interest] ID and IDREF
References: <MFBHCBDKCDCJBAAA@hotbot.com>
Message-ID: <39B57CAD.BA949D16@lutris.com>


veerpal singh wrote:
> 
> Hi All
> 
> I was just looking around on net for ID and IDREF processing. Is it possible thru jdom that when idref is encountered, element having iD can be retrieved. Or has to be done by higher level appl.

What do you need to be able to do, and what would you expect the API to
look like? Finally, what's your use-case for these changes.

Let us know, and I'll look at what it would take to do.

-Brett

> 
> Thanks
> VS
> 
> HotBot - Search smarter.
> http://www.hotbot.com
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org

From Murray.Altheim at eng.sun.com  Tue Sep  5 17:11:42 2000
From: Murray.Altheim at eng.sun.com (Murray Altheim)
Date: Fri Aug  6 17:04:47 2004
Subject: [jdom-interest] ID and IDREF
References: <MFBHCBDKCDCJBAAA@hotbot.com> <39B57CAD.BA949D16@lutris.com>
Message-ID: <39B58BBE.231B72AC@eng.sun.com>

Brett McLaughlin wrote:
> 
> veerpal singh wrote:
> >
> > Hi All
> >
> > I was just looking around on net for ID and IDREF processing. Is it 
> possible thru jdom that when idref is encountered, element having iD 
> can be retrieved. Or has to be done by higher level appl.
> 
> What do you need to be able to do, and what would you expect the API to
> look like? Finally, what's your use-case for these changes.
> 
> Let us know, and I'll look at what it would take to do.

I can't speak for Mr. Singh, but IDREF-ID processing is pretty common 
in some places, particularly intra-document links. As a use case example,
simple IDREF linking mechanism might look like:

    <!DOCTYPE book SYSTEM "book.dtd" [
    <!ELEMENT alink  EMPTY >
    <!ATTLIST alink 
        ref    IDREF    #REQUIRED
    >
    ]]>
    <book>
    <toc>
      <tocitem><alink ref="ss1">Section 1</alink>
      <tocitem><alink ref="ss2">Section 2</alink>
      <tocitem><alink ref="ss3">Section 3</alink>
    </toc>
    <sect1>
    <sect2 id="ss1"><title>Section 1</title>
    <para>...</para>
    </sect2>
    <sect2 id="ss2"><title>Section 1</title>
    <para>...</para>
    </sect2>
    <sect2 id="ss3"><title>Section 1</title>
    <para>...</para>
    </sect2>
    </sect1>
    </book>

The idea being that one would be able to easily retrieve a reference to
the element containing the ID pointed to by the IDREF, for navigation,
etc.  [It's kinda sad that HTML didn't use this mechanism rather than the
relative reference for internal links. It's a bit easier and would have
encouraged later HTML language designs to use IDs rather than 'name'
attributes (which are not of type ID, sadly), and we'd have avoided 
having both named and ID'd anchor targets.]

I'd encourage simple IDREF-ID links to be included in JDOM, but with a
proviso: if JDOM aims to be an API for well-formed XML, there's no solid
reason to include features that are particular to XML validation. If 
you're not already creating a hashtable of ID values, the overhead in
terms of memory and performance is probably not worth it, especially
on large documents. But if the hashtable is already there, this feature
request is relatively painless.

OTOH, if JDOM aims to provide an API useful for XML validation, it 
needs to provide *all* features that supportr XML 1.0 validation as
defined in the XML 1.0 Recommendation. Both ID validation (ie., validating
that all attribute values declared as type 'ID' are XML Names and are
unique) and IDREF-ID validation (ie., being able to ascertain that there
is an associated ID for all attribute values declared as type 'IDREF'
within the document) are part of XML 1.0 validation and must be included
if JDOM aims to provide a validation API. The ability to dereference the
IDREF value to a specific element would therefore be a byproduct of this
processing.

Murray

...........................................................................
Murray Altheim, SGML/XML Grease Monkey     <mailto:altheim&#64;eng.sun.com>
XML Technology Center
Sun Microsystems, 1601 Willow Rd., MS UMPK17-102, Menlo Park, CA 94025

      In the evening
      The rice leaves in the garden
      Rustle in the autumn wind
      That blows through my reed hut.  -- Minamoto no Tsunenobu

From metatype at yahoo.com  Tue Sep  5 17:25:34 2000
From: metatype at yahoo.com (Anthony Baker)
Date: Fri Aug  6 17:04:47 2004
Subject: [jdom-interest] ID and IDREF
Message-ID: <20000906002534.17448.qmail@web215.mail.yahoo.com>

> Message: 17
> Date: Tue, 05 Sep 2000 18:07:25 -0500
> From: "Brett McLaughlin"
> <brett.mclaughlin@lutris.com>
> Organization: Lutris Technologies
> To: veerpal@hotbot.com
> CC: jdom-interest@jdom.org
> Subject: Re: [jdom-interest] ID and IDREF
> 
> 
> 
> veerpal singh wrote:
> > 
> > Hi All
> > 
> > I was just looking around on net for ID and IDREF
> processing. Is it possible thru jdom that when idref
> is encountered, element having iD can be retrieved.
> Or has to be done by higher level appl.
> 
> What do you need to be able to do, and what would
> you expect the API to
> look like? Finally, what's your use-case for these
> changes.
> 

The thing I would want to do is exchange an IDREF for
an element ref.  The api could look like:

myElement.getAttribute("otherElement").getElement();

In case the "otherElement" attribute isn't an IDREF,
it would be an error.  The use-case here is for
metadata types of information, where parts of
documents refer to other parts.  I'm not sure whether
to use the XML mechanism or application-level
interpretation (like the ejb spec uses names within
the deployment descriptors).

Thanks,
Anthony

> Let us know, and I'll look at what it would take to
> do.
> 
> -Brett
> 
> > 
> > Thanks
> > VS
> > 
> > HotBot - Search smarter.
> > http://www.hotbot.com
> > _______________________________________________
> > To control your jdom-interest membership:
> >
>
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
> 
> -- 
> Brett McLaughlin, Enhydra Strategist
> Lutris Technologies, Inc. 
> 1200 Pacific Avenue, Suite 300 
> Santa Cruz, CA 95060 USA 
> http://www.lutris.com
> http://www.enhydra.org
> 


__________________________________________________
Do You Yahoo!?
Yahoo! Mail - Free email you can access from anywhere!
http://mail.yahoo.com/

From guru at edamame.stinky.com  Tue Sep  5 11:56:13 2000
From: guru at edamame.stinky.com (Alex Chaffee)
Date: Fri Aug  6 17:04:47 2004
Subject: [jdom-interest] cvs is down
Message-ID: <20000905115613.E14729@edamame.stinky.com>

I can't sync to cvs.  I get the message

can't create temporary directory
No space left on device

This is from two different machines, with plenty of space, so I figure
it's the remote machine that's out.

 - A

-- 
Alex Chaffee                       mailto:alex@jguru.com
jGuru - Java News and FAQs         http://www.jguru.com/alex/
Creator of Gamelan                 http://www.gamelan.com/
Founder of Purple Technology       http://www.purpletech.com/
Curator of Stinky Art Collective   http://www.stinky.com/

From mago at mail.internet.com.mx  Tue Sep  5 19:34:02 2000
From: mago at mail.internet.com.mx (Gerardo Horvilleur)
Date: Fri Aug  6 17:04:47 2004
Subject: [jdom-interest] JDOM as a Database API?
References: <39B48637.7CA8E246@mail.internet.com.mx> <39B48C86.A0382D31@collab.net> <39B4950B.8A3953D9@mail.internet.com.mx> <39B4BA0B.994E03E@lutris.com>
Message-ID: <39B5AD1A.6485352D@mail.internet.com.mx>

Brett McLaughlin wrote:
> I'm very much against this, for several reasons.
> 
> First, the core principle of JDOM is that it is an in-memory structure,
> and is pure Java objects until it is outputted, and inputted. In other
> words, a document doesn't have to be well-formed, valid, etc., except
> when inpit and output occurs. Not tying the in-memory representation to
> XML, databases, or anything else keeps us portable, light, and udeful.
> 
> Second, and building on that, you add a tremendous amount of overhead to
> every call. Writing to a database, actually checking the database
> schema, and all the problems you incur with this behavior make JDOM a
> heavyweight API in this case.
> 
> Third, you abandon all portability. I should be able to build a JDOM
> Document from any input form, manipulate it in the same fashion, and
> output it to any supported output form. This ability to move from one
> input (SAX, DOM, JDOM, RDBMS) to the /same/ internal representation, to
> any other output format (SAX, DOM, JDOM, RDBMS) and chaining the calls
> is what, IMO, makes JDOM really cool.
> 
> While certainly you can do what you are wanting (it is open-source!),
> I'm suggesting that you not, and rethink your decision; adding input and
> output from a database is something I'd like to see, but adding
> automatic committal, etc., isn't something I would endorse or want to
> encourage users to do (i.e. by putting it in jdom-contrib). Think it
> over, and I think you'll see that input and output are better ideas.

I can't say I agree with you.

But on the other hand, I do like JDOM's ease of use and I believe you might be
right in being so reluctant to accept any extensions which could compromise its
simplicity.

As it turns out, although I really like the idea of using JDOM as a database API
I don't need this right away. So I will think carefully about it, and if I still
think it is a good idea I will write a design document explaining why I need it
and how I intend to implement it. Then, before I do anything else about it, I'll send
this document to you (and anybody else you tell me to) so I can get your feedback.

Is this OK with you?

-- 

Gerardo Horvilleur
mago@mail.internet.com.mx

From brett.mclaughlin at lutris.com  Tue Sep  5 20:06:30 2000
From: brett.mclaughlin at lutris.com (Brett McLaughlin)
Date: Fri Aug  6 17:04:47 2004
Subject: [jdom-interest] JDOM as a Database API?
References: <39B48637.7CA8E246@mail.internet.com.mx> <39B48C86.A0382D31@collab.net> <39B4950B.8A3953D9@mail.internet.com.mx> <39B4BA0B.994E03E@lutris.com> <39B5AD1A.6485352D@mail.internet.com.mx>
Message-ID: <39B5B4B6.DC9D413E@lutris.com>


Gerardo Horvilleur wrote:
> 
> Brett McLaughlin wrote:
> > I'm very much against this, for several reasons.
> >
> > First, the core principle of JDOM is that it is an in-memory structure,
> > and is pure Java objects until it is outputted, and inputted. In other
> > words, a document doesn't have to be well-formed, valid, etc., except
> > when inpit and output occurs. Not tying the in-memory representation to
> > XML, databases, or anything else keeps us portable, light, and udeful.
> >
> > Second, and building on that, you add a tremendous amount of overhead to
> > every call. Writing to a database, actually checking the database
> > schema, and all the problems you incur with this behavior make JDOM a
> > heavyweight API in this case.
> >
> > Third, you abandon all portability. I should be able to build a JDOM
> > Document from any input form, manipulate it in the same fashion, and
> > output it to any supported output form. This ability to move from one
> > input (SAX, DOM, JDOM, RDBMS) to the /same/ internal representation, to
> > any other output format (SAX, DOM, JDOM, RDBMS) and chaining the calls
> > is what, IMO, makes JDOM really cool.
> >
> > While certainly you can do what you are wanting (it is open-source!),
> > I'm suggesting that you not, and rethink your decision; adding input and
> > output from a database is something I'd like to see, but adding
> > automatic committal, etc., isn't something I would endorse or want to
> > encourage users to do (i.e. by putting it in jdom-contrib). Think it
> > over, and I think you'll see that input and output are better ideas.
> 
> I can't say I agree with you.
> 
> But on the other hand, I do like JDOM's ease of use and I believe you might be
> right in being so reluctant to accept any extensions which could compromise its
> simplicity.
> 
> As it turns out, although I really like the idea of using JDOM as a database API
> I don't need this right away. So I will think carefully about it, and if I still
> think it is a good idea I will write a design document explaining why I need it
> and how I intend to implement it. Then, before I do anything else about it, I'll send
> this document to you (and anybody else you tell me to) so I can get your feedback.

Excellent - send it to this list, and we can all talk about it and
discuss it. And like I said, it may be that a compromise, using input
and output, works great, and that would be core API. We'll see...

Thanks for being willing to work at the design - that's a sign of wisdom
;-)

-Brett

> 
> Is this OK with you?
> 
> --
> 
> Gerardo Horvilleur
> mago@mail.internet.com.mx

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org

From jhunter at collab.net  Tue Sep  5 20:12:35 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:04:47 2004
Subject: [jdom-interest] Re: cvs is down
References: <20000905115613.E14729@edamame.stinky.com>
Message-ID: <39B5B623.402727D0@collab.net>

> I can't sync to cvs.  I get the message
> 
> can't create temporary directory
> No space left on device
> 
> This is from two different machines, with plenty of space, so I figure
> it's the remote machine that's out.

Same error for me.  Too bad it's 4am Jools-time.  Gotta wait til he
wakes up to rm that /tmp dir.

New action item:  Get some cvs account privs set up so Brett and I (and
probably others who are CVS savvy and read this list a lot) can do
something in situations like this.

-jh-

From guyn at tantian.com  Wed Sep  6 01:21:27 2000
From: guyn at tantian.com (Guy Nirpaz)
Date: Fri Aug  6 17:04:47 2004
Subject: [jdom-interest] Convert XML data to Java ojbects
References: <00f001c01730$43b99a00$080aa8c0@tantian.local> <39B50451.9FF7F001@lutris.com>
Message-ID: <007201c017dd$30f02670$080aa8c0@tantian.local>

>
> OK. Makes sense. Now could you explain (to others) why you would use
> your methodology instead of data binding? Data Binding would create the
> Person class for you, create the Address class for you, and then using a
> Marshaller and Unmarshaller, convert back and forth. There wouldn't be a
> need for this, if you used data binding... let us know what use case
> this fills that a more standard methodoogy doesn't.
>
> -Brett
>

Ok,

I'm working in a J2EE environment. The data that is roaming in the system is
XML. I needed a way to map XML to EntityBeans in both directions.

At first I realized that I'm adding a toXML() method to every EntityBean. I
needed a more generic way of doing that. This resulted in a generic
converter from EntityBean to XML.

In the opposite direction - constructing EntityBean out of XML was a much
more complex problem. At first I looked at the solution of Data Binding. The
problem was that EntityBeans should not be created at run time. EntityBeans
are coded and than deployed to an Enterprise Container. I needed a way to
map XML to predefined EntityBean objects.

While coding this generic mapping - I realized that it's good enough not
just to EJB's but also to other standard Java objects.

Currently I find it very useful. I took a design approach that enables one
to extend the basic functionality of the conversion to whatever needed by
scenario (EJB's among other scenarios)

- Guy


From cpiqueres at tissat.es  Wed Sep  6 01:05:00 2000
From: cpiqueres at tissat.es (Carlos Piqueres Ayela)
Date: Fri Aug  6 17:04:47 2004
Subject: [jdom-interest] copy subtree
Message-ID: <39B5FAAC.2F25D9DF@tissat.es>

Hi everybody,

Is there a way to copy or clone a document fragment from one document to
another??

TIA


From jhunter at collab.net  Wed Sep  6 01:53:43 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:04:47 2004
Subject: [jdom-interest] copy subtree
References: <39B5FAAC.2F25D9DF@tissat.es>
Message-ID: <39B60617.5669CB16@collab.net>

> Is there a way to copy or clone a document fragment from one 
> document to another??

How 'bout the getCopy() and clone() methods.  

-jh-

From tsasala at hifusion.com  Wed Sep  6 04:20:21 2000
From: tsasala at hifusion.com (tsasala@hifusion.com)
Date: Fri Aug  6 17:04:47 2004
Subject: [jdom-interest] copy subtree
References: <39B5FAAC.2F25D9DF@tissat.es>
Message-ID: <39B62875.D1AE472E@hifusion.com>

	getChildren returns the subtree.

Carlos Piqueres Ayela wrote:
> 
> Hi everybody,
> 
> Is there a way to copy or clone a document fragment from one document to
> another??
> 
> TIA
> 
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com

From EGalluzzo at synchrony.net  Wed Sep  6 06:48:22 2000
From: EGalluzzo at synchrony.net (Galluzzo, Eric)
Date: Fri Aug  6 17:04:48 2004
Subject: [jdom-interest] ID and IDREF
Message-ID: <51C6625F6F63D211853B0008C74C1A1EFA77AD@corp-exchg-001.synchrony.net>

> -----Original Message-----
> From: Brett McLaughlin [mailto:brett.mclaughlin@lutris.com]
> 
> veerpal singh wrote:
> > 
> > Hi All
> > 
> > I was just looking around on net for ID and IDREF 
> processing. Is it possible thru jdom that when idref is 
> encountered, element having iD can be retrieved. Or has to be 
> done by higher level appl.
> 
> What do you need to be able to do, and what would you expect 
> the API to
> look like? Finally, what's your use-case for these changes.
> 
> Let us know, and I'll look at what it would take to do.

I could actually use this too. :)  We're modeling contacts with XML.  Many
contacts can share a person and/or an organization, so we have something
inside the contact that references (via an IDREF) a person and an
organization (each identified via an ID), thus:

    ...

    <contacts>
      <contact>
        <person-ref person="p1"/>
        <org-ref org="o1"/>
        ...
      </contact>
      ...
    </contacts>

    <people>
      <person id="p1">
        ...
      </person>
      ...
    </people>

    <orgs>
      <org id="o1">
        ...
      </org>
      ...
    </orgs>

    ...

It would be very handy to go something like:

    Document doc         = ...;
    Element  contactElem = ...;
    String   personID    =
        contactElem.getChild ("person-ref").getAttribute ("ref").getValue();
    Element  personElem  = doc.getElementFromID (personID);

Of course, if we had the XPath stuff, I could just go something like:

    Element personElem =
        doc.resolveQuery ("id(//contact[1]/person-ref/@person)");

but that's somewhat of a pipe dream. :)

It would make sense to me to put the getElementFromID() method on Document,
since the Document is the only thing that could know about all the elements
within a document.  Also, it contains the Doctype by which one can tell
whether an element is an ID or not.

One problem I can foresee is that maintaining some sort of ID -> element map
while the user is constructing a document will be really quite painful, and
perhaps even impossible.  For example, given:

    <!ELEMENT root (foo|bar)*>

    <!ELEMENT foo EMPTY>
    <!ATTLIST foo
        id  ID    #REQUIRED
    >

    <!ELEMENT bar EMPTY>
    <!ATTLIST bar
        foo IDREF #REQUIRED
    >

then:

    Document doc  = new Document();
    Element  root = new Element ("root");
    root.addContent (new Element ("foo").addAttribute ("id", "id0"));
    root.addContent (new Element ("bar").addAttribute ("foo", "id0"));
    doc.setRootElement (root);

would have to update the ID -> element map on the last statement, which
could be slow if root actually had lots more elements in it.  Likewise,
moving children about between documents and so on would become much trickier
for JDOM to implement.

So I would say the only feasible way to implement such a method would be to
do it "on the fly" -- in other words, to search through all attributes of
all elements until one is found with type "ID" and with the correct value.
But that's bound to be really, really slow.  So perhaps it's not even
feasible at all....

Anyway, if you've actually read this far, sorry for rambling on! :)

    - Eric

From dsmiley at mitre.org  Wed Sep  6 07:30:59 2000
From: dsmiley at mitre.org (David W. Smiley)
Date: Fri Aug  6 17:04:48 2004
Subject: [jdom-interest] Accessing Child Elements
References: <200009052318.RAA01920@dorothy.denveronline.net>
Message-ID: <39B65523.51560287@mitre.org>

...
>If the implementation were changed to:
> 
> public Element getChild(String name)
> {
>     return getChild(name, namespace); // use the enclosing namespace
> }
> 
> the behaviour in the for the no-namespaces-used remains the same as it
> is now and something more sensible is returned when namespaces are in
> use.
...

Sounds great to me!  Hard to disagree with this change.

-- David Smiley


From brett.mclaughlin at lutris.com  Wed Sep  6 08:19:43 2000
From: brett.mclaughlin at lutris.com (Brett McLaughlin)
Date: Fri Aug  6 17:04:48 2004
Subject: [jdom-interest] DOMOutputter changes
Message-ID: <39B6608F.5EAAE692@lutris.com>

All-

  Yusuf is doing well lately ;-) I just committed a patch by Yusuf to
allow DOMOutputter to output a DOM Element from a JDOM Element. This, in
tandem with his earlier patch to allow building a JDOM Element from a
DOM Element, makes us nice and friendly with those DOM guys. So check it
out, it's in CVS.

Thanks,
Brett

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org

From jools at jools.org  Wed Sep  6 09:26:51 2000
From: jools at jools.org (Jools Enticknap)
Date: Fri Aug  6 17:04:48 2004
Subject: [jdom-interest] Source snapshots
Message-ID: <39B6704B.409E2E97@jools.org>

**If you don't download source snapshots via http://cvs.jdom.org please
hit delete now.**


Hi

A disk filled up on cvs.jdom.org and was not noticed until today, this
means that the
snapshot's were not being created, and CVS was being hampered too.

The problem has now been resolved and I've manaually generated the new
archives.

If you want to download the latest and greatest, point your browser at
http://cvs.jdom.org



-Jools

From jhunter at collab.net  Wed Sep  6 09:51:13 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:04:48 2004
Subject: [jdom-interest] ID and IDREF
References: <51C6625F6F63D211853B0008C74C1A1EFA77AD@corp-exchg-001.synchrony.net>
Message-ID: <39B67601.80B004F1@collab.net>

> Of course, if we had the XPath stuff, I could just go something like:
> 
>     Element personElem =
>         doc.resolveQuery ("id(//contact[1]/person-ref/@person)");
> 
> but that's somewhat of a pipe dream. :)

Have you looked at the XPath work being done in jdom-contrib?  

-jh-

From scott at alodar.com  Wed Sep  6 10:07:34 2000
From: scott at alodar.com (Scott Ellsworth)
Date: Fri Aug  6 17:04:48 2004
Subject: [jdom-interest] Source snapshots
In-Reply-To: <39B6704B.409E2E97@jools.org>
Message-ID: <4.3.2.7.2.20000906100634.00b266f8@iceweasel.com>

Just got the following message when trying to pull the latest from 
cvs.jdom.org:

cvs server: cannot open directory /home/cvspublic/jdom/lib/bin: No such 
file or directory

This seems like a bit of a problem.  Is it an easy fix, or a nasty one?

Scott
Scott Ellsworth
scott@alodar.com


From Murray.Altheim at eng.sun.com  Wed Sep  6 10:57:10 2000
From: Murray.Altheim at eng.sun.com (Murray Altheim)
Date: Fri Aug  6 17:04:48 2004
Subject: [jdom-interest] ID and IDREF
References: <51C6625F6F63D211853B0008C74C1A1EFA77AD@corp-exchg-001.synchrony.net>
Message-ID: <39B68576.972ECA82@eng.sun.com>

"Galluzzo, Eric" wrote:
[...]
> One problem I can foresee is that maintaining some sort of ID -> element map
> while the user is constructing a document will be really quite painful, and
> perhaps even impossible.
> [...]
> would have to update the ID -> element map on the last statement, which
> could be slow if root actually had lots more elements in it.  Likewise,
> moving children about between documents and so on would become much trickier
> for JDOM to implement.
> 
> So I would say the only feasible way to implement such a method would be to
> do it "on the fly" -- in other words, to search through all attributes of
> all elements until one is found with type "ID" and with the correct value.
> But that's bound to be really, really slow.  So perhaps it's not even
> feasible at all....

You've identified various issues. First of all, in the absence of a DTD
(or other schema), it is impossible to know which attributes are declared
as type 'ID', and therefore there are *no* IDs in the document.

Assuming we have a schema available, and that IDs have been declared and
used in the document, it's a simple matter of keeping track of which 
attributes on which elements are of type ID, and then storing references
to elements containing instances of IDs in a hashtable. This is also how
you could ascertain if all IDs are unique. Prior to storing a new ID
value, the lookup *should* fail. Catch that exception and at that point
add the new ID to the hashtable. Then, at any point you need to dereference
an ID, a simple hash lookup provides the element reference. There may be
other ways of doing this, but this is at least how I've done it in my
parser. Performance is not really a problem, although on *enormous* 
documents the hashtable might be a memory hog. I've not seen this as 
a burden in my experience.

The idea of moving children between documents relies on the IDs in the 
source not overlapping the IDs in the destination. This should throw an
exception that would either cause the paste to fail, or automatically
reassign new IDs, probably at user preference. IDs are only valid within
the scope of their document of origin, so this by nature is a problem 
that should be solved in the context of the application environment. 

Keeping the API lightweight is important. If JDOM is being used for
validating parsers, then it must already support these features. It
almost sounds like one could have three components to an API:

  1. Core well-formed parsing (basically, SAX)
  2. XML 1.0 DTD parsing (SAX2 includes this)
  3. Database feature parsing

I'm not suggesting this, just noting that it's easy to overburden a 
design by pushing too many requirements its way.

Murray

...........................................................................
Murray Altheim, SGML/XML Grease Monkey     <mailto:altheim&#64;eng.sun.com>
XML Technology Center
Sun Microsystems, 1601 Willow Rd., MS UMPK17-102, Menlo Park, CA 94025

      In the evening
      The rice leaves in the garden
      Rustle in the autumn wind
      That blows through my reed hut.  -- Minamoto no Tsunenobu

From cloud09 at zdnetonebox.com  Wed Sep  6 10:58:15 2000
From: cloud09 at zdnetonebox.com (Art M Solano)
Date: Fri Aug  6 17:04:48 2004
Subject: [jdom-interest] jdom memory usage
Message-ID: <20000906175815.WCSR11668.mta04.onebox.com@onebox.com>

Hello,

I am new to the JDOM world (standard intelligence disclaimer).  In the
"Java and XML" book by Brett Mclaughlin, it states that:

"JDOM can perform at a level comparable to SAX, while still allowing
a tree structure to be kept in memory (through the JDOM document object),
and while still remaining more lightweight than DOM."

What is meant by performance of JDOM vrs SAX?  I gather that JDOM can
retrieve XML data at the same speed of SAX.

What is mean by more lightweight?  How does JDOM memory usage compare
to DOM?  Are there any figures for the current comparisons?

We are considering using JDOM for our data transfers, whereby several
gigs of xml may be transferred.  Due to this size, DOM is not an option.
 We like JDOM api much better than SAX.

cheers

art



-- 
Art Solano
cloud09@zdnetonebox.com - email
(703) 234-3967 ext. 1039 - voicemail/fax



___________________________________________________________________
To get your own FREE ZDNet Onebox - FREE voicemail, email, and fax,
all in one place - sign up today at http://www.zdnetonebox.com


From pvg at c-c-s.com  Wed Sep  6 11:31:27 2000
From: pvg at c-c-s.com (Peter V. Gadjokov)
Date: Fri Aug  6 17:04:48 2004
Subject: [jdom-interest] Accessing Child Elements
Message-ID: <704ECFDA88B3D311B5F000A0C959E5B601FBBB@adobo.c2labs.com>

 
There was another thread of discussion (under the 'API instability')
subject that went over this, I'd omitted to catch up with all the
traffic when I sent out my mail...

One of the issues was described by the following example by Jason
Hunter:

>To argue against myself and with Elliotte, another problem with 
>getChild("child") using the parent's namespace is that 

>Element kid = new Element("kid"); 
>parent.addContent(kid); 
>parent.getChild("kid"); 

>*wouldn't work* if the parent was in a namespace.  That's pretty 
>confusing.  With the current code it would work because kid would be in

>no namespace.  

It's been said that a JDOM tree can be unvaildated, badly formed and in
all sorts of intermediate states - this is undoubtedly useful,
programatically, but at the same time the classes and objects making up
the api have to represent something beyond 'an oddly constrained
tree/digraph with funny node names' so some contracts have to be
enforced and some amount of useful default behaviour has to be provided.
Doing this and keeping the API simple, flexible and easy to understand,
getting the balance right, can be quite tricky (and contentious and
fun).  

I'd argue that the current code 'works' but is wrong. It works well
enough for outputting the XML and getting the correct namespace scoping
but it doesn't _model_ the way namespaces actually work and that's
what's confusing. 
Element.getNamespace() should tell you what namespace an element is
_currently_ in, a new method is needed to query the namespace an element
was explicitly declared in. I think the following semantics would be
'intuitive':

- elements are instantiated in the default namespace when no namespace
  is given [no change]
- a new method is added to Element
    public Namespace getDeclaredNamespace();
  this would return the namespace the element was declared in, in JDOM,
  this declaration is immutable so it would return the namespace the
  Element was created with. 
- if an element is in the default namespace getNamespace should
  recursively find the enclosing explicitly declared namespace by
  walking up the tree. This models the way namespaces are 'lexically  
  scoped' in XML. 
- element.getChild(Element name) returns the element in the current
  enclosing namespace. It has to handle three success cases - 
  both parent and  child are in the default namespace, parent has
  an explicitly declared namespace while the child is in the default
  and (somewhat twisted) the parent is in-scope of some namespace
  declared 'above' it and the child has the same namespace but it's 
  declared explicitly. This sounds convoluted but if getNamespace()
  were modified as described above, the changes to getChild involve
  a simple addition of a call to getNamespace()

So, to walk through Jason's example - 


Element kid = new Element("kid"); // kid created, it is now in the def.
                                  // ns. and declared in the def. ns. 

// kid.getNamespace() should return default namespace
// as should kid.getDeclaredNamespace()

parent.addContent(kid);           // kid is added, neither element is 
                                  // modified other than setting up 
                                  // parent-child references but 
                                  // kid  should now be in 
                                  // the namespace of the parent. 

// kid.getNamespace().equals(parent.getNamespace())
// should return true, as should an identity comparison
// == since namespaces are uniqued
// kid.getDeclaredNamespace() should still return the default 
// namespace, no matter what getNamespace() returns now

parent.getChild("kid");            // kid is returned, since it is
looked
                                   // up in the namespace returned by
                                   // parent's getNamespace() call. 

// the kid essentially gets looked up by a getChild implementation in
// the parent that looks something like
// return getChild(kidName, getNamespace());


Comments?

-pvg

-----Original Message-----
From: David W. Smiley
To: Peter V. Gadjokov
Cc: jdom-interest@jdom.org
Sent: 9/6/00 7:30 AM
Subject: RE: [jdom-interest] Accessing Child Elements

...
>If the implementation were changed to:
> 
> public Element getChild(String name)
> {
>     return getChild(name, namespace); // use the enclosing namespace
> }
> 
> the behaviour in the for the no-namespaces-used remains the same as it
> is now and something more sensible is returned when namespaces are in
> use.
...

Sounds great to me!  Hard to disagree with this change.

-- David Smiley

_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@you
rhost.com

-----Original Message-----
From: David W. Smiley
To: Peter V. Gadjokov
Cc: jdom-interest@jdom.org
Sent: 9/6/00 7:30 AM
Subject: RE: [jdom-interest] Accessing Child Elements

...
>If the implementation were changed to:
> 
> public Element getChild(String name)
> {
>     return getChild(name, namespace); // use the enclosing namespace
> }
> 
> the behaviour in the for the no-namespaces-used remains the same as it
> is now and something more sensible is returned when namespaces are in
> use.
...

Sounds great to me!  Hard to disagree with this change.

-- David Smiley

_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@you
rhost.com

From chris.laprun at nist.gov  Wed Sep  6 11:39:44 2000
From: chris.laprun at nist.gov (Christophe D. Laprun)
Date: Fri Aug  6 17:04:48 2004
Subject: [jdom-interest] Build problem + getText bug ?
References: <39B6704B.409E2E97@jools.org>
Message-ID: <39B68F70.37B59B8F@nist.gov>

Hi all,

I had a bug with Element.getText so I updated my sources with the latest
version from the CVS and I got the following error when trying to build
jdom.jar:

BUILD CONFIG ERROR: Configuration property "dir" does not have a
setMethod in class org.apache.tools.ant.taskdefs.Replace
org.apache.tools.ant.BuildException: Configuration property "dir" does
not have a setMethod in class org.apache.tools.ant.taskdefs.Replace
	at org.apache.tools.ant.ProjectHelper.configure(ProjectHelper.java:336)
	at
org.apache.tools.ant.ProjectHelper.configureTasks(ProjectHelper.java:203)
	at
org.apache.tools.ant.ProjectHelper.configureTargets(ProjectHelper.java:174)
	at
org.apache.tools.ant.ProjectHelper.configureProject(ProjectHelper.java:133)
	at org.apache.tools.ant.Main.runBuild(Main.java:223)
	at org.apache.tools.ant.Main.main(Main.java:191)

The bug on getText is that for the document below, getText on a user
element doesn't return null but several blank lines...
<?xml version="1.0"?>
<!DOCTYPE log SYSTEM "../../../dtd/commlog.dtd">

<log wer="63.6">
<user stime="962315351.690000" etime="962315351.690000" wer="160.0">
   <ref>****** ** BARCE[LONA] /THROAT_CLEAR/ BARCELONA_SPAIN from ******
** DENVER_COLORADO </ref>
   <hyp>BOSTON TO BOSTON      OR             CHEYENNE        from DENVER
TO ROME            </hyp>
   <sco>I      I  S           S              S                    I     
I  S               </sco>
</user>
...

</log>

Can someone confirm or infirm that this is a bug ?

Thanks,

Chris

-- 
Christophe Laprun    [Ingenieur ISIMA, France / Guest researcher @NIST]
web: http://www.nist.gov/speech/staff/laprunch.htm
email: chris.laprun@nist.gov
phone: (301) 975 3191             fax: (301) 670 0939
--
The universe seems neither benign nor hostile, merely indifferent -
Sagan

From chris.laprun at nist.gov  Wed Sep  6 12:03:55 2000
From: chris.laprun at nist.gov (Christophe D. Laprun)
Date: Fri Aug  6 17:04:48 2004
Subject: [jdom-interest] Re: Build problem + getText bug ?
References: <39B6704B.409E2E97@jools.org> <39B68F70.37B59B8F@nist.gov>
Message-ID: <39B6951B.F42071F@nist.gov>

"Christophe D. Laprun" wrote:

> The bug on getText is that for the document below, getText on a user
> element doesn't return null but several blank lines...
> <?xml version="1.0"?>
> <!DOCTYPE log SYSTEM "../../../dtd/commlog.dtd">
> 
> <log wer="63.6">
> <user stime="962315351.690000" etime="962315351.690000" wer="160.0">
>    <ref>****** ** BARCE[LONA] /THROAT_CLEAR/ BARCELONA_SPAIN from ******
> ** DENVER_COLORADO </ref>
>    <hyp>BOSTON TO BOSTON      OR             CHEYENNE        from DENVER
> TO ROME            </hyp>
>    <sco>I      I  S           S              S                    I
> I  S               </sco>
> </user>
> ...
> 
> </log>
> 
> Can someone confirm or infirm that this is a bug ?

Hi again,

I think the problem is the indentation of the sub-elements. I didn't
realize that preserving whitespaces would actually consider indentation
as content... :( Sorry about this.

Chris 

-- 
Christophe Laprun    [Ingenieur ISIMA, France / Guest researcher @NIST]
web: http://www.nist.gov/speech/staff/laprunch.htm
email: chris.laprun@nist.gov
phone: (301) 975 3191             fax: (301) 670 0939
--
The universe seems neither benign nor hostile, merely indifferent -
Sagan

From EMorehouse at fool.com  Wed Sep  6 12:09:50 2000
From: EMorehouse at fool.com (Ed Morehouse)
Date: Fri Aug  6 17:04:48 2004
Subject: [jdom-interest] builders not preserving namespace attributes in xsl files
Message-ID: <39B6967E.48DE0C32@fool.com>

I came accross this problem when i tried to build an org.jdom.Document out of an
xsl file.  Both DOMBuilder and SAXBuilder seem to be ignoring all namespace
attributes except for the one for xsl itself.  Here is an example:



[ed@evilgenius xml]$ java -classpath
.:/usr/local/java/jdom/build/jdom.jar:/usr/local/java/xerces/xerces.jar BugDemo
foo-html.xsl 

----------------------------------------

here's an XML file:

----------------------------------------

<?xml version="1.0"?>

<xsl:stylesheet
	xmlns:JavaXML="http://www.oreilly.com/catalog/javaxml/"
	xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
	xmlns:foo="http://www.foo.com/bar"
	version="1.0">

	<xsl:template match="JavaXML:Book">
		<html>
			<head>
				<title><xsl:value-of select="JavaXML:Title" /></title>
			</head>
			<body>
				<xsl:apply-templates select="*[not(self::JavaXML:Title)]" />
			</body>
		</html>
	</xsl:template>

</xsl:stylesheet>

----------------------------------------

here's the same file after the SAXBuilder has its way with it:

----------------------------------------

<?xml version="1.0" encoding="UTF-8"?><xsl:stylesheet
xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">

	<xsl:template match="JavaXML:Book">
		<html>
			<head>
				<title><xsl:value-of select="JavaXML:Title" /></title>
			</head>
			<body>
				<xsl:apply-templates select="*[not(self::JavaXML:Title)]" />
			</body>
		</html>
	</xsl:template>

</xsl:stylesheet>
----------------------------------------

here's the same file after the DOMBuilder has its way with it:

----------------------------------------

<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE xsl:stylesheet><xsl:stylesheet
xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">

	<xsl:template match="JavaXML:Book">
		<html>
			<head>
				<title><xsl:value-of select="JavaXML:Title" /></title>
			</head>
			<body>
				<xsl:apply-templates select="*[not(self::JavaXML:Title)]" />
			</body>
		</html>
	</xsl:template>

</xsl:stylesheet>
----------------------------------------



The point to note is that there are three namespace declarations in the
xsl:stylesheet element in the input file but only one after the same file has
been run through either SAXBuilder or DOMBuilder.  This is clearly bad.  I've
been looking through the jdom source tree and suspect that the problem may be
with Xerces (by the way, in case you weren't reading carefully, i am using the
Apache Xerces parser in this example).

Could someone who understands this more than i please comment on this issue.  If
this is a bug wit Xerces i'll take it up with them, but some informed discussion
would be nice at this point.

The input file looks exactly like the first output segment.  Here is the source
of the program that generated the above output:



import org.jdom.input.SAXBuilder;
import org.jdom.input.DOMBuilder;
import org.jdom.output.XMLOutputter;

import java.io.File;
import java.io.InputStream;
import java.io.OutputStream;
import java.io.FileInputStream;

public class BugDemo 
	extends Object
{
	public static void main(String[] args)
		throws Exception
	{
		if (args.length == 1)
		{
			File file = new File(args[0]);
			new BugDemo().demoBug(file);
		}
		else
		{
			System.out.println("useage: java BugDemo <XMLFileName>");
		}
	}

	public void demoBug(File file)
		throws Exception
	{
		System.out.println("\n----------------------------------------\n");
		System.out.println("here's an XML file:");
		System.out.println("\n----------------------------------------\n");
		copyStream(new FileInputStream(file), System.out);
		System.out.println("\n----------------------------------------\n");
		System.out.println("here's the same file after the SAXBuilder has its way with
it:");
		System.out.println("\n----------------------------------------\n");
		new XMLOutputter().output(new SAXBuilder().build(file), System.out);
		System.out.println("\n----------------------------------------\n");
		System.out.println("here's the same file after the DOMBuilder has its way with
it:");
		System.out.println("\n----------------------------------------\n");
		new XMLOutputter().output(new DOMBuilder().build(file), System.out);
		System.out.println("\n----------------------------------------\n");
	}

	private void copyStream(InputStream in, OutputStream out)
		throws Exception
	{
		byte[] buffer = new byte[256];
		while (true)
		{
			int bytes = in.read(buffer);
			if (bytes == -1) break;
			out.write(buffer, 0, bytes);
		}
	}

}


 
                                  ------------
 
 - The happiest of people aren't the ones 
   who always have the best of everything;
   they are the ones who always make the best 
   of everything they have.

                                           Ed Morehouse
                                           Software Engineer/Evil Genius
                                           The Motley Fool

From bob at accurev.com  Wed Sep  6 12:16:32 2000
From: bob at accurev.com (bob)
Date: Fri Aug  6 17:04:48 2004
Subject: [jdom-interest] ID and IDREF
In-Reply-To: <39B67601.80B004F1@collab.net>
Message-ID: <Pine.LNX.3.96.1000906151444.21574V-100000@exeter.exeter.org>

> Have you looked at the XPath work being done in jdom-contrib?  

fwiw--

current XPath work got mired in Too Many Files in jdom-contrib,
and is currently heading towards stability on my local machine.

I've been gone for a while, and will sync up with CVS tonight,
and hopefully get an XPath package workikng against it (as opposed
to against my namespace-patched version).

I'll announce availability, and probably resubmit the whole
ball of wax as a replacement for the current jdom-contrib xpath
stuff.

	-bob


From dsmiley at mitre.org  Wed Sep  6 12:49:15 2000
From: dsmiley at mitre.org (David W. Smiley)
Date: Fri Aug  6 17:04:48 2004
Subject: [jdom-interest] Accessing Child Elements
References: <704ECFDA88B3D311B5F000A0C959E5B601FBBB@adobo.c2labs.com>
Message-ID: <39B69FBB.A78E431C@mitre.org>

> It's been said that a JDOM tree can be unvaildated, badly formed and in
> all sorts of intermediate states - this is undoubtedly useful,
> programatically, but at the same time the classes and objects making up
> the api have to represent something beyond 'an oddly constrained
> tree/digraph with funny node names' so some contracts have to be
> enforced and some amount of useful default behaviour has to be provided.

	True; although AFAIK I don't think JDOM as it exists now can become
invalidated.  Of course that change I mentioned previously that checks
to make sure that an element being added isn't an ancestor would have to
be added.

> Doing this and keeping the API simple, flexible and easy to understand,
> getting the balance right, can be quite tricky (and contentious and
> fun).
> 
> I'd argue that the current code 'works' but is wrong. It works well
> enough for outputting the XML and getting the correct namespace scoping
> but it doesn't _model_ the way namespaces actually work and that's
> what's confusing.
> Element.getNamespace() should tell you what namespace an element is
> _currently_ in, a new method is needed to query the namespace an element
> was explicitly declared in.

	What does that give you though?  I think a JDOM element should either
have a namespace set (explicit namespace) OR it should inherit the
namespace of the parent (implied namespace).  The only issue is making
sure that the namespace be maintained as an element is added / removed /
cloned.

...
> - if an element is in the default namespace getNamespace should
>   recursively find the enclosing explicitly declared namespace by
>   walking up the tree. This models the way namespaces are 'lexically  
>   scoped' in XML. 
...

	From what I understand about XML namespaces, they aren't lexically
scoped which is why "boston" has the default namespace instead of "us"
in this example:

<us:massachusetts>
	<boston>
</us:massachusetts>

See the FAQ: http://www.oasis-open.org/cover/NamespacesFAQ20000313.html
However, I do believe that JDOM, an api, should employ namespaces in a
way that /is/ lexically scoped... so that when you add "boston" to its
parent without specifying a namespace, you'd get "us:boston" instead.

-- David Smiley


From EGalluzzo at synchrony.net  Wed Sep  6 12:54:56 2000
From: EGalluzzo at synchrony.net (Galluzzo, Eric)
Date: Fri Aug  6 17:04:48 2004
Subject: [jdom-interest] Patch to build.xml
Message-ID: <51C6625F6F63D211853B0008C74C1A1EFA77B2@corp-exchg-001.synchrony.net>

Trying to build with JDK 1.1, I found that I needed to add the following at
line 109 of build.xml from the latest nightly source snapshot:

    <replace dir="${build.src}" includes="**"
             token="java.util.Set" value="${coll.import}.Set"/>
    <replace dir="${build.src}" includes="**"
             token="java.util.HashSet" value="${coll.import}.HashSet"/>

I'm afraid I'm on NT and so can't conveniently do a diff -c -- sorry about
that.  However, with this change, JDOM does compile successfully (I haven't
tried running anything with it yet, though).

	- Eric

-- 
Eric Galluzzo   <><
Product Engineer
Synchrony Communications, Inc.

Work: http://www.synchrony.net/
Home: http://w3.one.net/~eng/


From Brad.Morgan at e-pubcorp.com  Wed Sep  6 13:47:13 2000
From: Brad.Morgan at e-pubcorp.com (Brad Morgan)
Date: Fri Aug  6 17:04:48 2004
Subject: [jdom-interest] Build problem + getText bug ?
In-Reply-To: <39B68F70.37B59B8F@nist.gov>
Message-ID: <NDBBLFGNKKGCBIJEAIJBAEMBCGAA.Brad.Morgan@e-pubcorp.com>

I had the same "Build problem" but I fixed mine by getting the latest ant
from Apache.org (while I was getting the lastest xerces which doesn't seem
to be in CVS at the moment).

Now to find out how much trouble I'm really in! <G>

Regards,

Brad Morgan
e-Publishing Corp.

Email: Brad.Morgan@e-pubcorp.com
Phone: (719)593-7377 x35
Fax: (719)593-2996

e-Publishing Corp. is a BroadVision company
NOTICE: This message is intended only for the use of the Addressee and may
contain information that is PRIVILEGED and CONFIDENTIAL. If you are not the
intended recipient, dissemination of this communication is prohibited. If
you have received this communication in error, please erase all copies of
the message and its attachments and notify us immediately.



-----Original Message-----
From: jdom-interest-admin@jdom.org
[mailto:jdom-interest-admin@jdom.org]On Behalf Of Christophe D. Laprun
Sent: Wednesday, September 06, 2000 12:40 PM
Cc: jdom-interest@jdom.org
Subject: [jdom-interest] Build problem + getText bug ?


Hi all,

I had a bug with Element.getText so I updated my sources with the latest
version from the CVS and I got the following error when trying to build
jdom.jar:

BUILD CONFIG ERROR: Configuration property "dir" does not have a
setMethod in class org.apache.tools.ant.taskdefs.Replace
org.apache.tools.ant.BuildException: Configuration property "dir" does
not have a setMethod in class org.apache.tools.ant.taskdefs.Replace
	at org.apache.tools.ant.ProjectHelper.configure(ProjectHelper.java:336)
	at
org.apache.tools.ant.ProjectHelper.configureTasks(ProjectHelper.java:203)
	at
org.apache.tools.ant.ProjectHelper.configureTargets(ProjectHelper.java:174)
	at
org.apache.tools.ant.ProjectHelper.configureProject(ProjectHelper.java:133)
	at org.apache.tools.ant.Main.runBuild(Main.java:223)
	at org.apache.tools.ant.Main.main(Main.java:191)

The bug on getText is that for the document below, getText on a user
element doesn't return null but several blank lines...
<?xml version="1.0"?>
<!DOCTYPE log SYSTEM "../../../dtd/commlog.dtd">

<log wer="63.6">
<user stime="962315351.690000" etime="962315351.690000" wer="160.0">
   <ref>****** ** BARCE[LONA] /THROAT_CLEAR/ BARCELONA_SPAIN from ******
** DENVER_COLORADO </ref>
   <hyp>BOSTON TO BOSTON      OR             CHEYENNE        from DENVER
TO ROME            </hyp>
   <sco>I      I  S           S              S                    I
I  S               </sco>
</user>
...

</log>

Can someone confirm or infirm that this is a bug ?

Thanks,

Chris

--
Christophe Laprun    [Ingenieur ISIMA, France / Guest researcher @NIST]
web: http://www.nist.gov/speech/staff/laprunch.htm
email: chris.laprun@nist.gov
phone: (301) 975 3191             fax: (301) 670 0939
--
The universe seems neither benign nor hostile, merely indifferent -
Sagan
_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com


From brett.mclaughlin at lutris.com  Wed Sep  6 14:40:14 2000
From: brett.mclaughlin at lutris.com (Brett McLaughlin)
Date: Fri Aug  6 17:04:48 2004
Subject: [jdom-interest] builders not preserving namespace attributes in xsl 
 files
References: <39B6967E.48DE0C32@fool.com>
Message-ID: <39B6B9BE.4296316D@lutris.com>


Ed Morehouse wrote:
> 
> I came accross this problem when i tried to build an org.jdom.Document out of an
> xsl file.  Both DOMBuilder and SAXBuilder seem to be ignoring all namespace
> attributes except for the one for xsl itself.  Here is an example:

Get the latest version from CVS - this was a bug that just got a fix
done this week.

Let us know if that works.

-Brett

> 
> [ed@evilgenius xml]$ java -classpath
> .:/usr/local/java/jdom/build/jdom.jar:/usr/local/java/xerces/xerces.jar BugDemo
> foo-html.xsl
> 
> ----------------------------------------
> 
> here's an XML file:
> 
> ----------------------------------------
> 
> <?xml version="1.0"?>
> 
> <xsl:stylesheet
>         xmlns:JavaXML="http://www.oreilly.com/catalog/javaxml/"
>         xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
>         xmlns:foo="http://www.foo.com/bar"
>         version="1.0">
> 
>         <xsl:template match="JavaXML:Book">
>                 <html>
>                         <head>
>                                 <title><xsl:value-of select="JavaXML:Title" /></title>
>                         </head>
>                         <body>
>                                 <xsl:apply-templates select="*[not(self::JavaXML:Title)]" />
>                         </body>
>                 </html>
>         </xsl:template>
> 
> </xsl:stylesheet>
> 
> ----------------------------------------
> 
> here's the same file after the SAXBuilder has its way with it:
> 
> ----------------------------------------
> 
> <?xml version="1.0" encoding="UTF-8"?><xsl:stylesheet
> xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
> 
>         <xsl:template match="JavaXML:Book">
>                 <html>
>                         <head>
>                                 <title><xsl:value-of select="JavaXML:Title" /></title>
>                         </head>
>                         <body>
>                                 <xsl:apply-templates select="*[not(self::JavaXML:Title)]" />
>                         </body>
>                 </html>
>         </xsl:template>
> 
> </xsl:stylesheet>
> ----------------------------------------
> 
> here's the same file after the DOMBuilder has its way with it:
> 
> ----------------------------------------
> 
> <?xml version="1.0" encoding="UTF-8"?><!DOCTYPE xsl:stylesheet><xsl:stylesheet
> xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
> 
>         <xsl:template match="JavaXML:Book">
>                 <html>
>                         <head>
>                                 <title><xsl:value-of select="JavaXML:Title" /></title>
>                         </head>
>                         <body>
>                                 <xsl:apply-templates select="*[not(self::JavaXML:Title)]" />
>                         </body>
>                 </html>
>         </xsl:template>
> 
> </xsl:stylesheet>
> ----------------------------------------
> 
> The point to note is that there are three namespace declarations in the
> xsl:stylesheet element in the input file but only one after the same file has
> been run through either SAXBuilder or DOMBuilder.  This is clearly bad.  I've
> been looking through the jdom source tree and suspect that the problem may be
> with Xerces (by the way, in case you weren't reading carefully, i am using the
> Apache Xerces parser in this example).
> 
> Could someone who understands this more than i please comment on this issue.  If
> this is a bug wit Xerces i'll take it up with them, but some informed discussion
> would be nice at this point.
> 
> The input file looks exactly like the first output segment.  Here is the source
> of the program that generated the above output:
> 
> import org.jdom.input.SAXBuilder;
> import org.jdom.input.DOMBuilder;
> import org.jdom.output.XMLOutputter;
> 
> import java.io.File;
> import java.io.InputStream;
> import java.io.OutputStream;
> import java.io.FileInputStream;
> 
> public class BugDemo
>         extends Object
> {
>         public static void main(String[] args)
>                 throws Exception
>         {
>                 if (args.length == 1)
>                 {
>                         File file = new File(args[0]);
>                         new BugDemo().demoBug(file);
>                 }
>                 else
>                 {
>                         System.out.println("useage: java BugDemo <XMLFileName>");
>                 }
>         }
> 
>         public void demoBug(File file)
>                 throws Exception
>         {
>                 System.out.println("\n----------------------------------------\n");
>                 System.out.println("here's an XML file:");
>                 System.out.println("\n----------------------------------------\n");
>                 copyStream(new FileInputStream(file), System.out);
>                 System.out.println("\n----------------------------------------\n");
>                 System.out.println("here's the same file after the SAXBuilder has its way with
> it:");
>                 System.out.println("\n----------------------------------------\n");
>                 new XMLOutputter().output(new SAXBuilder().build(file), System.out);
>                 System.out.println("\n----------------------------------------\n");
>                 System.out.println("here's the same file after the DOMBuilder has its way with
> it:");
>                 System.out.println("\n----------------------------------------\n");
>                 new XMLOutputter().output(new DOMBuilder().build(file), System.out);
>                 System.out.println("\n----------------------------------------\n");
>         }
> 
>         private void copyStream(InputStream in, OutputStream out)
>                 throws Exception
>         {
>                 byte[] buffer = new byte[256];
>                 while (true)
>                 {
>                         int bytes = in.read(buffer);
>                         if (bytes == -1) break;
>                         out.write(buffer, 0, bytes);
>                 }
>         }
> 
> }
> 
> 
>                                   ------------
> 
>  - The happiest of people aren't the ones
>    who always have the best of everything;
>    they are the ones who always make the best
>    of everything they have.
> 
>                                            Ed Morehouse
>                                            Software Engineer/Evil Genius
>                                            The Motley Fool
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org

From jhunter at collab.net  Wed Sep  6 14:34:53 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:04:48 2004
Subject: [jdom-interest] Accessing Child Elements
References: <704ECFDA88B3D311B5F000A0C959E5B601FBBB@adobo.c2labs.com>
Message-ID: <39B6B87D.215A3F23@collab.net>

> Element.getNamespace() should tell you what namespace an element is
> _currently_ in, a new method is needed to query the namespace an 
> element was explicitly declared in. 

That's similar to how we started off with JDOM, but it was successfully
argued that an element's namespace is an intrinsic part of that element,
just as a Java class' namespace is a part of that class.  As such the
namespace should be held with the class during moves between documents
and moves within a document, and not "inherited" depending on where it's
placed.

-jh-

From jhunter at collab.net  Wed Sep  6 14:49:05 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:04:48 2004
Subject: [jdom-interest] builders not preserving namespace attributes in xsl 
 files
References: <39B6967E.48DE0C32@fool.com>
Message-ID: <39B6BBD1.E995D763@collab.net>

Ed Morehouse wrote:
> 
> I came accross this problem... 

Please include which version you're using.

(How come no one ever does this?  As developers don't we all have to
read bug reports, and don't you always want to know which version the
bug is reported against?)

-jh-

From k_svanberg at yahoo.se  Wed Sep  6 12:30:56 2000
From: k_svanberg at yahoo.se (=?iso-8859-1?q?Kennet=20Svanberg?=)
Date: Fri Aug  6 17:04:48 2004
Subject: [jdom-interest] (no subject)
Message-ID: <20000906193056.11554.qmail@web6304.mail.yahoo.com>

Hi all,
have I understood the code in XMLOutputter correct:
if the following document would be output, the line
starting with <!ENTITY would NOT be printed but
everthing else?
Is this made on purpose? would it be useful to have a
setXXX to include/suppress this part of the document.
Or am I possibly the only one still using DTDs...

<?xml version="1.0" ?>
<!DOCTYPE nodes SYSTEM "http://127.0.0.1:8080" [
<!ENTITY pics SYSTEM "../pics/pic.gif" >
]>
<nodes>
	<node>Some content</node>
	<graphics name="pics"/>
	<othernode>Other content</othernode>
</nodes>

-Kennet Svanberg

_____________________________________________________
Do You Yahoo!?
Ditt_namn@yahoo.se - skaffa en gratis mailadress p? http://mail.yahoo.se

From pvg at c-c-s.com  Wed Sep  6 15:01:46 2000
From: pvg at c-c-s.com (Peter V. Gadjokov)
Date: Fri Aug  6 17:04:48 2004
Subject: [jdom-interest] Accessing Child Elements
Message-ID: <704ECFDA88B3D311B5F000A0C959E5B601FBBC@adobo.c2labs.com>

Following up on my own post... There is another way of looking at this
which perhaps comes closer to Elioette's i-like-my-namespaces-explicit 
worldview. My last proposal assumes that the rules of namespace scoping 
should be modeled directly by the API and its implementation. It's 
perfectly possible to toss this assumption and get consistent and 
intuitive API behaviour. It goes something like this - 

All elements have an explicit namespace declaration. How that namespace
declaration is represented in the XML output is the business of the XML
outputter, in the JDOM (java object) representation, all elements
have explicit, immutable namespace declarations with no inheritence
or propagation rules. There are no distinguished namespaces such
as the default namespace  - the distinguished nature of the default
namespace is an artifact of the textual representation of XML belongs
in the java<->xml text conversion facilities and not in the core 
Java API. The intrinsic methods of element creation and lookup all
require an explicit namespace. All other variants of these methods are 
convenience methods with clearly documented semantics appropriate for
the particular method. 

What this all means - 

new Element("name") - create element in the empty namespace [no change]
  This is the only place a specific namespace is assumed and
  it is the empty namespace (xmlns="", if declared explicitly in XML
  text), for lack of any other sensible choice. If one
  wanted to be an anal purist, this constructor could simply be 
  removed. Users who need it could  write a trivial subclass 
  or trivial factory that provides this functionality. 

the namespace-less variants of get/remove child/children all use
the parent/receiver namespace as context. This is intuitive  - 
that's the only namespace they could possibly assume given that
all elements have a namespace and no namespace is special. If you're
asking an element for another element and provide no namespace, the
only sensible assumption the receiver can make is that you're asking
for something in _its_ namespace. This applies to the getCopy methods
and attribute related methods as well. The lack of 'default namespace'
semantics improves the conceptual simplicity of the API - in the case
of attirbutes, there is no need to explain that default namespaces
do not apply to attributes.

Aside for the changes in Element for  implicit lookup, outputters
would have to be modified to treat NO_NAMESPACE as the _empty_ as
opposed to the default namespace. The notion of a default namespace
would not exist in the JDOM. This approach has a certain appeal -
the complexity of the scoping rules is reduced and that makes sense
in an object model - you're navigating an instance graph and you can
easily ask any instance to tell you what it is. In other words, 
every Element already has a getNamespace() method, every Element
is already 'explicitly annotated' by virtue of the API. The 'default 
namespace' semantics are only useful when the XML is represented
as text, they can arguably help make the textual representation
more compact or more readable. An object model or a  Java instance 
graph has no such requirement. [A non-xml example of this is is the
representation of Java type names in source and at runtime, in a
particular piece of source a given type might be represented
as Foo, FooMaster.Foo or  com.fooborama.FooMaster.Foo, the
runtime only stores/cares about/tracks a stable, unique, FQ'ed name
that can be obtained for any instance of Foo by calling 
getClass().getName()]   
 
To use Jason Hunter's example again - 

// Create an element in the empty NS (or impossible if the constructor
// were removed entirely)
Element kid = new Element("kid");    

// Add the child...
parent.addContent(kid); 

// Retreieve the child
parent.getChild("kid"); 

This would work iff parent were in the empty namespace as kid. It would 
not work if parent were in some other namespace. Is that a big deal? I
don't think it is. It may be a little confusing at first to people 
who are used to staring at a lot of XML text - but the API should cater
to Java programmers and present a consistent OO model - a model that 
allows accurate, deterministic, bidirectional conversion to XML but
is not burdened with every wart and detail of the textual 
representation. Chances are, as XML gains popularity, writing and
reading XML text manually will become a less-common chore and almost
all XML manipulation will be done programatically. It seems best to 
focus on programmatic representations that are sensible and easy 
for programmers to use at the cost of (when neccessary and possible)
of modelling  every of the textual representation.

What would the above changes mean for current code? 
If you're not using namespaces, everything works as it did before. 
If you are using namespaces, expecting some default behaviour other
than some assumption based on the namespace of the receiver is not
sensible. If you are using namespaces, you're best off being explicit
when instantiating (improves the maintainability of
the code anyway) and relying on the implicit lookup only when your
code has a strong built-in knowledge of the structure of the tags
its manipulating (usually the case). Potentially, a convenience
creation method could be added to Element for lazy typists

Element createChild(String name)
{
    Element newChild = new Element(name, namespace);
    return addContent(newChild);
}


As more and more systems employ XML, particularly for the purposes
of interoperability, namespaces become crucial. We're less 
likely to be seeing much code with no namespace use at all as time
goes on - namespace-capable JDOM code should be the assumed to be 
the default use-case. The simplicity and ease of writing and using 
namespace-capable code should take precedence i.e. if the API is
going to have convenience methods that make assumptions, those
assumptions should be such that make namespace-capable code easier
to write and use. 

-pvg

From k_svanberg at yahoo.se  Wed Sep  6 12:30:56 2000
From: k_svanberg at yahoo.se (=?iso-8859-1?q?Kennet=20Svanberg?=)
Date: Fri Aug  6 17:04:48 2004
Subject: [jdom-interest] (no subject)
Message-ID: <20000906193056.11554.qmail@web6304.mail.yahoo.com>

Hi all,
have I understood the code in XMLOutputter correct:
if the following document would be output, the line
starting with <!ENTITY would NOT be printed but
everthing else?
Is this made on purpose? would it be useful to have a
setXXX to include/suppress this part of the document.
Or am I possibly the only one still using DTDs...

<?xml version="1.0" ?>
<!DOCTYPE nodes SYSTEM "http://127.0.0.1:8080" [
<!ENTITY pics SYSTEM "../pics/pic.gif" >
]>
<nodes>
	<node>Some content</node>
	<graphics name="pics"/>
	<othernode>Other content</othernode>
</nodes>

-Kennet Svanberg

_____________________________________________________
Do You Yahoo!?
Ditt_namn@yahoo.se - skaffa en gratis mailadress p? http://mail.yahoo.se

From pvg at c-c-s.com  Wed Sep  6 15:05:58 2000
From: pvg at c-c-s.com (Peter V. Gadjokov)
Date: Fri Aug  6 17:04:48 2004
Subject: [jdom-interest] Accessing Child Elements
Message-ID: <704ECFDA88B3D311B5F000A0C959E5B6129FE7@adobo.c2labs.com>

 
Agreed. I just fired off a proposal that is based on that argument (in
fact, I used java type names as an example as well) but has more 
intuitive behaviour when no namespace is specified and enforces the
'no weird namespace scoping' notion strongly. I would implement the 
neccessary changes if we agree on them. 

-pvg


-----Original Message-----
From: Jason Hunter
To: Peter V. Gadjokov
Cc: 'David W. Smiley '; 'jdom-interest@jdom.org '
Sent: 9/6/00 2:34 PM
Subject: Re: [jdom-interest] Accessing Child Elements

> Element.getNamespace() should tell you what namespace an element is
> _currently_ in, a new method is needed to query the namespace an 
> element was explicitly declared in. 

That's similar to how we started off with JDOM, but it was successfully
argued that an element's namespace is an intrinsic part of that element,
just as a Java class' namespace is a part of that class.  As such the
namespace should be held with the class during moves between documents
and moves within a document, and not "inherited" depending on where it's
placed.

-jh-

From dsmiley at mitre.org  Wed Sep  6 15:07:15 2000
From: dsmiley at mitre.org (David W. Smiley)
Date: Fri Aug  6 17:04:48 2004
Subject: [jdom-interest] Accessing Child Elements
References: <704ECFDA88B3D311B5F000A0C959E5B601FBBB@adobo.c2labs.com> <39B6B87D.215A3F23@collab.net>
Message-ID: <39B6C013.9D22913B@mitre.org>

Jason Hunter wrote:
> 
> > Element.getNamespace() should tell you what namespace an element is
> > _currently_ in, a new method is needed to query the namespace an
> > element was explicitly declared in.
> 
> That's similar to how we started off with JDOM, but it was successfully
> argued that an element's namespace is an intrinsic part of that element,
> just as a Java class' namespace is a part of that class.

	--you could have that argument for any system in which namespaces are
used; it means nothing.  Namespaces are about convenience.  Does
"successfully argued" mean that Peter, myself, and others are
effectively stone-walled against the powers that be on this issue?

>As such the
> namespace should be held with the class during moves between documents
> and moves within a document, and not "inherited" depending on where it's
> placed.

	** My namespace implementation proposition is true to this. **

I really hope Peter & I are not wasting our time  >:-|

-- David Smiley


From k_svanberg at yahoo.se  Wed Sep  6 12:30:56 2000
From: k_svanberg at yahoo.se (=?iso-8859-1?q?Kennet=20Svanberg?=)
Date: Fri Aug  6 17:04:48 2004
Subject: [jdom-interest] (no subject)
Message-ID: <20000906193056.11554.qmail@web6304.mail.yahoo.com>

Hi all,
have I understood the code in XMLOutputter correct:
if the following document would be output, the line
starting with <!ENTITY would NOT be printed but
everthing else?
Is this made on purpose? would it be useful to have a
setXXX to include/suppress this part of the document.
Or am I possibly the only one still using DTDs...

<?xml version="1.0" ?>
<!DOCTYPE nodes SYSTEM "http://127.0.0.1:8080" [
<!ENTITY pics SYSTEM "../pics/pic.gif" >
]>
<nodes>
	<node>Some content</node>
	<graphics name="pics"/>
	<othernode>Other content</othernode>
</nodes>

-Kennet Svanberg

_____________________________________________________
Do You Yahoo!?
Ditt_namn@yahoo.se - skaffa en gratis mailadress p? http://mail.yahoo.se

From k_svanberg at yahoo.se  Wed Sep  6 12:30:56 2000
From: k_svanberg at yahoo.se (=?iso-8859-1?q?Kennet=20Svanberg?=)
Date: Fri Aug  6 17:04:48 2004
Subject: [jdom-interest] (no subject)
Message-ID: <20000906193056.11554.qmail@web6304.mail.yahoo.com>

Hi all,
have I understood the code in XMLOutputter correct:
if the following document would be output, the line
starting with <!ENTITY would NOT be printed but
everthing else?
Is this made on purpose? would it be useful to have a
setXXX to include/suppress this part of the document.
Or am I possibly the only one still using DTDs...

<?xml version="1.0" ?>
<!DOCTYPE nodes SYSTEM "http://127.0.0.1:8080" [
<!ENTITY pics SYSTEM "../pics/pic.gif" >
]>
<nodes>
	<node>Some content</node>
	<graphics name="pics"/>
	<othernode>Other content</othernode>
</nodes>

-Kennet Svanberg

_____________________________________________________
Do You Yahoo!?
Ditt_namn@yahoo.se - skaffa en gratis mailadress p? http://mail.yahoo.se

From jhunter at collab.net  Wed Sep  6 15:12:20 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:04:48 2004
Subject: [jdom-interest] Patch to build.xml
References: <51C6625F6F63D211853B0008C74C1A1EFA77B2@corp-exchg-001.synchrony.net>
Message-ID: <39B6C144.821B3BB6@collab.net>

> Trying to build with JDK 1.1, I found that I needed to add the 
> following at line 109 of build.xml from the latest nightly 
> source snapshot:
> 
>     <replace dir="${build.src}" includes="**"
>              token="java.util.Set" value="${coll.import}.Set"/>
>     <replace dir="${build.src}" includes="**"
>              token="java.util.HashSet"
> value="${coll.import}.HashSet"/>

Good catch.  Set and HashSet are now used in XMLOutputter, so JDK 1.1
needs more replace rules.  

We could add all 20 some replace options but that just slows down the
build.  We could also go to using java.util.* instead of explicit
declaration per class; that'd mean we only need one replace rule.

Anyway, I checked in your fix.

-jh-

From k_svanberg at yahoo.se  Wed Sep  6 12:30:56 2000
From: k_svanberg at yahoo.se (=?iso-8859-1?q?Kennet=20Svanberg?=)
Date: Fri Aug  6 17:04:48 2004
Subject: [jdom-interest] (no subject)
Message-ID: <20000906193056.11554.qmail@web6304.mail.yahoo.com>

Hi all,
have I understood the code in XMLOutputter correct:
if the following document would be output, the line
starting with <!ENTITY would NOT be printed but
everthing else?
Is this made on purpose? would it be useful to have a
setXXX to include/suppress this part of the document.
Or am I possibly the only one still using DTDs...

<?xml version="1.0" ?>
<!DOCTYPE nodes SYSTEM "http://127.0.0.1:8080" [
<!ENTITY pics SYSTEM "../pics/pic.gif" >
]>
<nodes>
	<node>Some content</node>
	<graphics name="pics"/>
	<othernode>Other content</othernode>
</nodes>

-Kennet Svanberg

_____________________________________________________
Do You Yahoo!?
Ditt_namn@yahoo.se - skaffa en gratis mailadress p? http://mail.yahoo.se

From jhunter at collab.net  Wed Sep  6 15:20:16 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:04:48 2004
Subject: [jdom-interest] Accessing Child Elements
References: <704ECFDA88B3D311B5F000A0C959E5B601FBBB@adobo.c2labs.com> <39B6B87D.215A3F23@collab.net> <39B6C013.9D22913B@mitre.org>
Message-ID: <39B6C320.AC9739B6@collab.net>

> --you could have that argument for any system in which namespaces are
> used; it means nothing.  Namespaces are about convenience.  

Namespaces are more than convenience, but I'll let Elliotte talk to that
if he wants.  :-)

> Does
> "successfully argued" mean that Peter, myself, and others are
> effectively stone-walled against the powers that be on this issue?

Course not, but it means it's not a new idea and was publicly debated
and the decision was already made once.  There needs to be convincing
new arguments to change the decision after the fact.

-jh-

From jhunter at collab.net  Wed Sep  6 15:13:47 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:04:48 2004
Subject: [jdom-interest] Build problem + getText bug ?
References: <NDBBLFGNKKGCBIJEAIJBAEMBCGAA.Brad.Morgan@e-pubcorp.com>
Message-ID: <39B6C19B.6F2F97EF@collab.net>

Brad Morgan wrote:
> 
> I had the same "Build problem" but I fixed mine by getting the 
> latest ant from Apache.org (while I was getting the lastest 
> xerces which doesn't seem to be in CVS at the moment).

The server problem seemed to have affected the lib dir.  I re-checked in
modern versions of the JARs (not sure I got the latest xerces.jar we had
before, Brett can take care of that).

-jh-

From k_svanberg at yahoo.se  Wed Sep  6 12:30:56 2000
From: k_svanberg at yahoo.se (=?iso-8859-1?q?Kennet=20Svanberg?=)
Date: Fri Aug  6 17:04:48 2004
Subject: [jdom-interest] (no subject)
Message-ID: <20000906193056.11554.qmail@web6304.mail.yahoo.com>

Hi all,
have I understood the code in XMLOutputter correct:
if the following document would be output, the line
starting with <!ENTITY would NOT be printed but
everthing else?
Is this made on purpose? would it be useful to have a
setXXX to include/suppress this part of the document.
Or am I possibly the only one still using DTDs...

<?xml version="1.0" ?>
<!DOCTYPE nodes SYSTEM "http://127.0.0.1:8080" [
<!ENTITY pics SYSTEM "../pics/pic.gif" >
]>
<nodes>
	<node>Some content</node>
	<graphics name="pics"/>
	<othernode>Other content</othernode>
</nodes>

-Kennet Svanberg

_____________________________________________________
Do You Yahoo!?
Ditt_namn@yahoo.se - skaffa en gratis mailadress p? http://mail.yahoo.se

From k_svanberg at yahoo.se  Wed Sep  6 12:30:56 2000
From: k_svanberg at yahoo.se (=?iso-8859-1?q?Kennet=20Svanberg?=)
Date: Fri Aug  6 17:04:48 2004
Subject: [jdom-interest] (no subject)
Message-ID: <20000906193056.11554.qmail@web6304.mail.yahoo.com>

Hi all,
have I understood the code in XMLOutputter correct:
if the following document would be output, the line
starting with <!ENTITY would NOT be printed but
everthing else?
Is this made on purpose? would it be useful to have a
setXXX to include/suppress this part of the document.
Or am I possibly the only one still using DTDs...

<?xml version="1.0" ?>
<!DOCTYPE nodes SYSTEM "http://127.0.0.1:8080" [
<!ENTITY pics SYSTEM "../pics/pic.gif" >
]>
<nodes>
	<node>Some content</node>
	<graphics name="pics"/>
	<othernode>Other content</othernode>
</nodes>

-Kennet Svanberg

_____________________________________________________
Do You Yahoo!?
Ditt_namn@yahoo.se - skaffa en gratis mailadress p? http://mail.yahoo.se

From k_svanberg at yahoo.se  Wed Sep  6 12:30:56 2000
From: k_svanberg at yahoo.se (=?iso-8859-1?q?Kennet=20Svanberg?=)
Date: Fri Aug  6 17:04:48 2004
Subject: [jdom-interest] (no subject)
Message-ID: <20000906193056.11554.qmail@web6304.mail.yahoo.com>

Hi all,
have I understood the code in XMLOutputter correct:
if the following document would be output, the line
starting with <!ENTITY would NOT be printed but
everthing else?
Is this made on purpose? would it be useful to have a
setXXX to include/suppress this part of the document.
Or am I possibly the only one still using DTDs...

<?xml version="1.0" ?>
<!DOCTYPE nodes SYSTEM "http://127.0.0.1:8080" [
<!ENTITY pics SYSTEM "../pics/pic.gif" >
]>
<nodes>
	<node>Some content</node>
	<graphics name="pics"/>
	<othernode>Other content</othernode>
</nodes>

-Kennet Svanberg

_____________________________________________________
Do You Yahoo!?
Ditt_namn@yahoo.se - skaffa en gratis mailadress p? http://mail.yahoo.se

From k_svanberg at yahoo.se  Wed Sep  6 12:30:56 2000
From: k_svanberg at yahoo.se (=?iso-8859-1?q?Kennet=20Svanberg?=)
Date: Fri Aug  6 17:04:48 2004
Subject: [jdom-interest] (no subject)
Message-ID: <20000906193056.11554.qmail@web6304.mail.yahoo.com>

Hi all,
have I understood the code in XMLOutputter correct:
if the following document would be output, the line
starting with <!ENTITY would NOT be printed but
everthing else?
Is this made on purpose? would it be useful to have a
setXXX to include/suppress this part of the document.
Or am I possibly the only one still using DTDs...

<?xml version="1.0" ?>
<!DOCTYPE nodes SYSTEM "http://127.0.0.1:8080" [
<!ENTITY pics SYSTEM "../pics/pic.gif" >
]>
<nodes>
	<node>Some content</node>
	<graphics name="pics"/>
	<othernode>Other content</othernode>
</nodes>

-Kennet Svanberg

_____________________________________________________
Do You Yahoo!?
Ditt_namn@yahoo.se - skaffa en gratis mailadress p? http://mail.yahoo.se

From k_svanberg at yahoo.se  Wed Sep  6 12:30:56 2000
From: k_svanberg at yahoo.se (=?iso-8859-1?q?Kennet=20Svanberg?=)
Date: Fri Aug  6 17:04:48 2004
Subject: [jdom-interest] (no subject)
Message-ID: <20000906193056.11554.qmail@web6304.mail.yahoo.com>

Hi all,
have I understood the code in XMLOutputter correct:
if the following document would be output, the line
starting with <!ENTITY would NOT be printed but
everthing else?
Is this made on purpose? would it be useful to have a
setXXX to include/suppress this part of the document.
Or am I possibly the only one still using DTDs...

<?xml version="1.0" ?>
<!DOCTYPE nodes SYSTEM "http://127.0.0.1:8080" [
<!ENTITY pics SYSTEM "../pics/pic.gif" >
]>
<nodes>
	<node>Some content</node>
	<graphics name="pics"/>
	<othernode>Other content</othernode>
</nodes>

-Kennet Svanberg

_____________________________________________________
Do You Yahoo!?
Ditt_namn@yahoo.se - skaffa en gratis mailadress p? http://mail.yahoo.se

From k_svanberg at yahoo.se  Wed Sep  6 12:30:56 2000
From: k_svanberg at yahoo.se (=?iso-8859-1?q?Kennet=20Svanberg?=)
Date: Fri Aug  6 17:04:48 2004
Subject: [jdom-interest] (no subject)
Message-ID: <20000906193056.11554.qmail@web6304.mail.yahoo.com>

Hi all,
have I understood the code in XMLOutputter correct:
if the following document would be output, the line
starting with <!ENTITY would NOT be printed but
everthing else?
Is this made on purpose? would it be useful to have a
setXXX to include/suppress this part of the document.
Or am I possibly the only one still using DTDs...

<?xml version="1.0" ?>
<!DOCTYPE nodes SYSTEM "http://127.0.0.1:8080" [
<!ENTITY pics SYSTEM "../pics/pic.gif" >
]>
<nodes>
	<node>Some content</node>
	<graphics name="pics"/>
	<othernode>Other content</othernode>
</nodes>

-Kennet Svanberg

_____________________________________________________
Do You Yahoo!?
Ditt_namn@yahoo.se - skaffa en gratis mailadress p? http://mail.yahoo.se

From pvg at c-c-s.com  Wed Sep  6 15:53:03 2000
From: pvg at c-c-s.com (Peter V. Gadjokov)
Date: Fri Aug  6 17:04:48 2004
Subject: [jdom-interest] builders not preserving namespace attributes 
	in xsl  files
Message-ID: <704ECFDA88B3D311B5F000A0C959E5B601FBBE@adobo.c2labs.com>

 
>(How come no one ever does this?  As developers don't we all have to
>read bug reports, and don't you always want to know which version the
>bug is reported against?)

Perhaps this is worth mentioning in the 'getting involved area' of the
website - asking for JDK/jdom/xerces version and stack traces (a -g
default build target would be helpful as well, if it is not already
the case) if  the problem generates an exception. The daily snapshots
could also be named with a UTC yearmonthday string included so all
versions can be distinguished by milestone/version/snapshot number
or 'fresh from cvs'.

-pvg

From k_svanberg at yahoo.se  Wed Sep  6 12:30:56 2000
From: k_svanberg at yahoo.se (=?iso-8859-1?q?Kennet=20Svanberg?=)
Date: Fri Aug  6 17:04:48 2004
Subject: [jdom-interest] (no subject)
Message-ID: <20000906193056.11554.qmail@web6304.mail.yahoo.com>

Hi all,
have I understood the code in XMLOutputter correct:
if the following document would be output, the line
starting with <!ENTITY would NOT be printed but
everthing else?
Is this made on purpose? would it be useful to have a
setXXX to include/suppress this part of the document.
Or am I possibly the only one still using DTDs...

<?xml version="1.0" ?>
<!DOCTYPE nodes SYSTEM "http://127.0.0.1:8080" [
<!ENTITY pics SYSTEM "../pics/pic.gif" >
]>
<nodes>
	<node>Some content</node>
	<graphics name="pics"/>
	<othernode>Other content</othernode>
</nodes>

-Kennet Svanberg

_____________________________________________________
Do You Yahoo!?
Ditt_namn@yahoo.se - skaffa en gratis mailadress p? http://mail.yahoo.se

From k_svanberg at yahoo.se  Wed Sep  6 12:30:56 2000
From: k_svanberg at yahoo.se (=?iso-8859-1?q?Kennet=20Svanberg?=)
Date: Fri Aug  6 17:04:48 2004
Subject: [jdom-interest] (no subject)
Message-ID: <20000906193056.11554.qmail@web6304.mail.yahoo.com>

Hi all,
have I understood the code in XMLOutputter correct:
if the following document would be output, the line
starting with <!ENTITY would NOT be printed but
everthing else?
Is this made on purpose? would it be useful to have a
setXXX to include/suppress this part of the document.
Or am I possibly the only one still using DTDs...

<?xml version="1.0" ?>
<!DOCTYPE nodes SYSTEM "http://127.0.0.1:8080" [
<!ENTITY pics SYSTEM "../pics/pic.gif" >
]>
<nodes>
	<node>Some content</node>
	<graphics name="pics"/>
	<othernode>Other content</othernode>
</nodes>

-Kennet Svanberg

_____________________________________________________
Do You Yahoo!?
Ditt_namn@yahoo.se - skaffa en gratis mailadress p? http://mail.yahoo.se

From jhunter at collab.net  Wed Sep  6 15:55:38 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:04:48 2004
Subject: [jdom-interest] (no subject)
References: <20000906193056.11554.qmail@web6304.mail.yahoo.com>
Message-ID: <39B6CB6A.920977F4@collab.net>

Kennet Svanberg wrote:
> 
> Hi all,

I at least have gotten about a dozen copies of this email so far.  Not
sure what the cause is, the archives list it only once, the message id
header is identical for all of them, and the initial delivery time from
denveronline.net is the same for all of them too.  It's later in the
delivery cycle that the one msg seems to have become a dozen.

Weird...

-jh-

From dsmiley at mitre.org  Wed Sep  6 16:04:25 2000
From: dsmiley at mitre.org (David W. Smiley)
Date: Fri Aug  6 17:04:48 2004
Subject: [jdom-interest] Accessing Child Elements
References: <704ECFDA88B3D311B5F000A0C959E5B601FBBB@adobo.c2labs.com> <39B6B87D.215A3F23@collab.net> <39B6C013.9D22913B@mitre.org> <39B6C320.AC9739B6@collab.net>
Message-ID: <39B6CD79.69127679@mitre.org>

Jason Hunter wrote:
> 
> > --you could have that argument for any system in which namespaces are
> > used; it means nothing.  Namespaces are about convenience.
> 
> Namespaces are more than convenience, but I'll let Elliotte talk to that
> if he wants.  :-)

	Of course, I did not mean to imply that.  The main point was that your
saying that a FQ'd name is intrinsic to the object does not mean that
one must be explicit when creating/identifying objects in all cases. 
Your argument does not take into consideration the convenience of
namespaces.

	Hey Peter, I read your recommendation and it looks good to me.  I agree
with your main points, as they are the main points of my
recommendation.  The difference is that my recommendation suggested that
newly created Elements not have a namespace so that when they are added
to some other element, that it be inherited.  You don't have this, but
you suggested a createChild method which makes my behavior easier to
get.  All I said about inheritance of the namespace field is an
implementation detail so that when adding an element you don't have to
visit all elements in the tree to change the field.

-- David Smiley


From EMorehouse at fool.com  Wed Sep  6 16:00:42 2000
From: EMorehouse at fool.com (Ed Morehouse)
Date: Fri Aug  6 17:04:48 2004
Subject: [jdom-interest] builders not preserving namespace attributes in xsl 
 files
References: <39B6967E.48DE0C32@fool.com> <39B6BBD1.E995D763@collab.net>
Message-ID: <39B6CC9A.D3DFCE20@fool.com>

I apologize.

I was using the jdom source tree i checked out from cvs this morning at 11:26am
EDT, Xerces-J version 1.2.0 dated September 1st, and Sun's jdk 1.2.2 for linux.

I just did a fresh checkout of the jdom tree at 6:40pm, built it and ran it with
the same results.

If others are unable to reproduce my results then perhaps i am doing something
unusual that i am not aware i am doing, but i have tried to minimize the risk of
this possibility by using the latest sources available and keeping the test case
as simple as possible.

Any help would be appreciated.

-Ed


Jason Hunter wrote:
> 
> Ed Morehouse wrote:
> >
> > I came accross this problem...
> 
> Please include which version you're using.
> 
> (How come no one ever does this?  As developers don't we all have to
> read bug reports, and don't you always want to know which version the
> bug is reported against?)
> 
> -jh-

-- 
                                  ------------
 
 - The happiest of people aren't the ones 
   who always have the best of everything;
   they are the ones who always make the best 
   of everything they have.

                                           Ed Morehouse
                                           Software Engineer/Evil Genius
                                           The Motley Fool

From k_svanberg at yahoo.se  Wed Sep  6 12:30:56 2000
From: k_svanberg at yahoo.se (=?iso-8859-1?q?Kennet=20Svanberg?=)
Date: Fri Aug  6 17:04:48 2004
Subject: [jdom-interest] (no subject)
Message-ID: <20000906193056.11554.qmail@web6304.mail.yahoo.com>

Hi all,
have I understood the code in XMLOutputter correct:
if the following document would be output, the line
starting with <!ENTITY would NOT be printed but
everthing else?
Is this made on purpose? would it be useful to have a
setXXX to include/suppress this part of the document.
Or am I possibly the only one still using DTDs...

<?xml version="1.0" ?>
<!DOCTYPE nodes SYSTEM "http://127.0.0.1:8080" [
<!ENTITY pics SYSTEM "../pics/pic.gif" >
]>
<nodes>
	<node>Some content</node>
	<graphics name="pics"/>
	<othernode>Other content</othernode>
</nodes>

-Kennet Svanberg

_____________________________________________________
Do You Yahoo!?
Ditt_namn@yahoo.se - skaffa en gratis mailadress p? http://mail.yahoo.se

From pvg at c-c-s.com  Wed Sep  6 16:09:57 2000
From: pvg at c-c-s.com (Peter V. Gadjokov)
Date: Fri Aug  6 17:04:48 2004
Subject: [jdom-interest] Accessing Child Elements
Message-ID: <704ECFDA88B3D311B5F000A0C959E5B601FBBF@adobo.c2labs.com>

[pvg] Element.getNamespace() should tell you what namespace an element
is
[pvg]_currently_ in, a new method is needed to query the namespace an
[pvg] element was explicitly declared in.

>What does that give you though?  I think a JDOM element should
>either have a namespace set (explicit namespace) OR it should 
>inherit the namespace of the parent (implied namespace).  The
>only issue is making sure that the namespace be maintained as
>an element is added / removed / cloned.

It doesn't give you an awful lot, other than being able to tell whether
an element is inheriting a namespace from its context or whether
it has an explicitly declared namespace. It lets you distinguish 
between what boils down to a 'dynamically typed' or 
'statically typed' element, dynamically typed elements being ones
that can be moved to a new context and aquire their type from it,
while retaining their structure. Having given it some further
thought, I've decided that this is not a concept worth supporting
and is most likely not the intent of the namespace specification. 
The namespace inheritence/scoping rules are an artifact of the
textual XML representation that need not be modelled in the Java API.


>	From what I understand about XML namespaces, they aren't
>lexically scoped which is why "boston" has the default namespace
>instead of "us" in this example: [...]

Yes, I should not have used such a specific term - I meant that
the scoping was 'lexical-like' with respect to the XML namespace
_declaration_, i.e. the declaration is the environment, not the 
element. If an element contains an unprefixed declaration, all
unprefixed sub-elements are in that namespace. 
To take this abuse of terminology a little further, I think what
you are  (and I was) describing amounts to the _ability_ to have
dynamic scoping when you want it by using the default namespace.
Why am I calling it dynamic? Because what it boils down is having
elements whose 'type' is not tied to some environment at time of
declaration (instantiation) but is defined by the environment it
is contained in at a given time. My motivation for proposing the
change was getting more sensible behaviour in the default,
namespaceless convenience methods, the scoping behaviour came 
out as a side effect. As I said, I've convinced myself that this
type of dynamic behaviour is undesirable in the Java API, it ends
up modelling something that I think is purely an artifact of 
the specification for textual representation. I do still want
getChild, new Element, etc to behave more consistently so I've
modified my proposal - I've proposed eliminating NO_NAMESPACE
as a distinguished namespace (by changing the default behaviour
of the convenience methods) and enforcing the notion of a unique,
immutable namespace declaration for every element (bound at
instantiation), both at runtime and when serialized. I think it
clarifies the API semantics, makes the convenience methods behave
more predictably/usefully and is in the spirit of the current 
implementation - there are no complex scoping rules. That framework
can still support utility methods to ease moving/copying an element
to a different document with a different namespace or even tag name.

[Since I started the whole language terminology abuse, I'll take
the irrelevant analogies further - I think what you're/I was 
asking for is the ability to have 'structural' vs 'name' type 
equivalence. I.e. if two element 'types' (namespace+tagname) are 
structurally equivalent, you want to be able to use them in
different contexts and not worry about re-specifying the type 
explicitly. Java/C++/Pascal/most other statically typed languages
rely on name type-equivalence (structurally identical types
with different names are  considered different types), the model
is intuitively familiar to most and I think JDOM should continue
to emulate it when it comes to Elements and Namespaces. 
Even-more-irrelevant-aside - Modula 3 (of, uhm, cvsup fame :)
is statically typed and  has structural type equivalence]

-pvg

From k_svanberg at yahoo.se  Wed Sep  6 12:30:56 2000
From: k_svanberg at yahoo.se (=?iso-8859-1?q?Kennet=20Svanberg?=)
Date: Fri Aug  6 17:04:48 2004
Subject: [jdom-interest] (no subject)
Message-ID: <20000906193056.11554.qmail@web6304.mail.yahoo.com>

Hi all,
have I understood the code in XMLOutputter correct:
if the following document would be output, the line
starting with <!ENTITY would NOT be printed but
everthing else?
Is this made on purpose? would it be useful to have a
setXXX to include/suppress this part of the document.
Or am I possibly the only one still using DTDs...

<?xml version="1.0" ?>
<!DOCTYPE nodes SYSTEM "http://127.0.0.1:8080" [
<!ENTITY pics SYSTEM "../pics/pic.gif" >
]>
<nodes>
	<node>Some content</node>
	<graphics name="pics"/>
	<othernode>Other content</othernode>
</nodes>

-Kennet Svanberg

_____________________________________________________
Do You Yahoo!?
Ditt_namn@yahoo.se - skaffa en gratis mailadress p? http://mail.yahoo.se

From k_svanberg at yahoo.se  Wed Sep  6 12:30:56 2000
From: k_svanberg at yahoo.se (=?iso-8859-1?q?Kennet=20Svanberg?=)
Date: Fri Aug  6 17:04:48 2004
Subject: [jdom-interest] (no subject)
Message-ID: <20000906193056.11554.qmail@web6304.mail.yahoo.com>

Hi all,
have I understood the code in XMLOutputter correct:
if the following document would be output, the line
starting with <!ENTITY would NOT be printed but
everthing else?
Is this made on purpose? would it be useful to have a
setXXX to include/suppress this part of the document.
Or am I possibly the only one still using DTDs...

<?xml version="1.0" ?>
<!DOCTYPE nodes SYSTEM "http://127.0.0.1:8080" [
<!ENTITY pics SYSTEM "../pics/pic.gif" >
]>
<nodes>
	<node>Some content</node>
	<graphics name="pics"/>
	<othernode>Other content</othernode>
</nodes>

-Kennet Svanberg

_____________________________________________________
Do You Yahoo!?
Ditt_namn@yahoo.se - skaffa en gratis mailadress p? http://mail.yahoo.se

From k_svanberg at yahoo.se  Wed Sep  6 12:30:56 2000
From: k_svanberg at yahoo.se (=?iso-8859-1?q?Kennet=20Svanberg?=)
Date: Fri Aug  6 17:04:48 2004
Subject: [jdom-interest] (no subject)
Message-ID: <20000906193056.11554.qmail@web6304.mail.yahoo.com>

Hi all,
have I understood the code in XMLOutputter correct:
if the following document would be output, the line
starting with <!ENTITY would NOT be printed but
everthing else?
Is this made on purpose? would it be useful to have a
setXXX to include/suppress this part of the document.
Or am I possibly the only one still using DTDs...

<?xml version="1.0" ?>
<!DOCTYPE nodes SYSTEM "http://127.0.0.1:8080" [
<!ENTITY pics SYSTEM "../pics/pic.gif" >
]>
<nodes>
	<node>Some content</node>
	<graphics name="pics"/>
	<othernode>Other content</othernode>
</nodes>

-Kennet Svanberg

_____________________________________________________
Do You Yahoo!?
Ditt_namn@yahoo.se - skaffa en gratis mailadress p? http://mail.yahoo.se

From k_svanberg at yahoo.se  Wed Sep  6 12:30:56 2000
From: k_svanberg at yahoo.se (=?iso-8859-1?q?Kennet=20Svanberg?=)
Date: Fri Aug  6 17:04:48 2004
Subject: [jdom-interest] (no subject)
Message-ID: <20000906193056.11554.qmail@web6304.mail.yahoo.com>

Hi all,
have I understood the code in XMLOutputter correct:
if the following document would be output, the line
starting with <!ENTITY would NOT be printed but
everthing else?
Is this made on purpose? would it be useful to have a
setXXX to include/suppress this part of the document.
Or am I possibly the only one still using DTDs...

<?xml version="1.0" ?>
<!DOCTYPE nodes SYSTEM "http://127.0.0.1:8080" [
<!ENTITY pics SYSTEM "../pics/pic.gif" >
]>
<nodes>
	<node>Some content</node>
	<graphics name="pics"/>
	<othernode>Other content</othernode>
</nodes>

-Kennet Svanberg

_____________________________________________________
Do You Yahoo!?
Ditt_namn@yahoo.se - skaffa en gratis mailadress p? http://mail.yahoo.se

From k_svanberg at yahoo.se  Wed Sep  6 12:30:56 2000
From: k_svanberg at yahoo.se (=?iso-8859-1?q?Kennet=20Svanberg?=)
Date: Fri Aug  6 17:04:48 2004
Subject: [jdom-interest] (no subject)
Message-ID: <20000906193056.11554.qmail@web6304.mail.yahoo.com>

Hi all,
have I understood the code in XMLOutputter correct:
if the following document would be output, the line
starting with <!ENTITY would NOT be printed but
everthing else?
Is this made on purpose? would it be useful to have a
setXXX to include/suppress this part of the document.
Or am I possibly the only one still using DTDs...

<?xml version="1.0" ?>
<!DOCTYPE nodes SYSTEM "http://127.0.0.1:8080" [
<!ENTITY pics SYSTEM "../pics/pic.gif" >
]>
<nodes>
	<node>Some content</node>
	<graphics name="pics"/>
	<othernode>Other content</othernode>
</nodes>

-Kennet Svanberg

_____________________________________________________
Do You Yahoo!?
Ditt_namn@yahoo.se - skaffa en gratis mailadress p? http://mail.yahoo.se

From k_svanberg at yahoo.se  Wed Sep  6 12:30:56 2000
From: k_svanberg at yahoo.se (=?iso-8859-1?q?Kennet=20Svanberg?=)
Date: Fri Aug  6 17:04:48 2004
Subject: [jdom-interest] (no subject)
Message-ID: <20000906193056.11554.qmail@web6304.mail.yahoo.com>

Hi all,
have I understood the code in XMLOutputter correct:
if the following document would be output, the line
starting with <!ENTITY would NOT be printed but
everthing else?
Is this made on purpose? would it be useful to have a
setXXX to include/suppress this part of the document.
Or am I possibly the only one still using DTDs...

<?xml version="1.0" ?>
<!DOCTYPE nodes SYSTEM "http://127.0.0.1:8080" [
<!ENTITY pics SYSTEM "../pics/pic.gif" >
]>
<nodes>
	<node>Some content</node>
	<graphics name="pics"/>
	<othernode>Other content</othernode>
</nodes>

-Kennet Svanberg

_____________________________________________________
Do You Yahoo!?
Ditt_namn@yahoo.se - skaffa en gratis mailadress p? http://mail.yahoo.se

From k_svanberg at yahoo.se  Wed Sep  6 12:30:56 2000
From: k_svanberg at yahoo.se (=?iso-8859-1?q?Kennet=20Svanberg?=)
Date: Fri Aug  6 17:04:48 2004
Subject: [jdom-interest] (no subject)
Message-ID: <20000906193056.11554.qmail@web6304.mail.yahoo.com>

Hi all,
have I understood the code in XMLOutputter correct:
if the following document would be output, the line
starting with <!ENTITY would NOT be printed but
everthing else?
Is this made on purpose? would it be useful to have a
setXXX to include/suppress this part of the document.
Or am I possibly the only one still using DTDs...

<?xml version="1.0" ?>
<!DOCTYPE nodes SYSTEM "http://127.0.0.1:8080" [
<!ENTITY pics SYSTEM "../pics/pic.gif" >
]>
<nodes>
	<node>Some content</node>
	<graphics name="pics"/>
	<othernode>Other content</othernode>
</nodes>

-Kennet Svanberg

_____________________________________________________
Do You Yahoo!?
Ditt_namn@yahoo.se - skaffa en gratis mailadress p? http://mail.yahoo.se

From k_svanberg at yahoo.se  Wed Sep  6 12:30:56 2000
From: k_svanberg at yahoo.se (=?iso-8859-1?q?Kennet=20Svanberg?=)
Date: Fri Aug  6 17:04:48 2004
Subject: [jdom-interest] (no subject)
Message-ID: <20000906193056.11554.qmail@web6304.mail.yahoo.com>

Hi all,
have I understood the code in XMLOutputter correct:
if the following document would be output, the line
starting with <!ENTITY would NOT be printed but
everthing else?
Is this made on purpose? would it be useful to have a
setXXX to include/suppress this part of the document.
Or am I possibly the only one still using DTDs...

<?xml version="1.0" ?>
<!DOCTYPE nodes SYSTEM "http://127.0.0.1:8080" [
<!ENTITY pics SYSTEM "../pics/pic.gif" >
]>
<nodes>
	<node>Some content</node>
	<graphics name="pics"/>
	<othernode>Other content</othernode>
</nodes>

-Kennet Svanberg

_____________________________________________________
Do You Yahoo!?
Ditt_namn@yahoo.se - skaffa en gratis mailadress p? http://mail.yahoo.se

From brett.mclaughlin at lutris.com  Wed Sep  6 17:13:58 2000
From: brett.mclaughlin at lutris.com (Brett McLaughlin)
Date: Fri Aug  6 17:04:48 2004
Subject: [jdom-interest] builders not preserving namespace attributes in xsl 
 files
References: <39B6967E.48DE0C32@fool.com> <39B6BBD1.E995D763@collab.net> <39B6CC9A.D3DFCE20@fool.com>
Message-ID: <39B6DDC6.31F2EA2@lutris.com>

Ed Morehouse wrote:
> 
> I apologize.
> 
> I was using the jdom source tree i checked out from cvs this morning at 11:26am
> EDT, Xerces-J version 1.2.0 dated September 1st, and Sun's jdk 1.2.2 for linux.
> 
> I just did a fresh checkout of the jdom tree at 6:40pm, built it and ran it with
> the same results.

Yep, it's a bug. I'll work on it tonight or tomorrow...

-Brett

> 
> If others are unable to reproduce my results then perhaps i am doing something
> unusual that i am not aware i am doing, but i have tried to minimize the risk of
> this possibility by using the latest sources available and keeping the test case
> as simple as possible.
> 
> Any help would be appreciated.
> 
> -Ed
> 
> Jason Hunter wrote:
> >
> > Ed Morehouse wrote:
> > >
> > > I came accross this problem...
> >
> > Please include which version you're using.
> >
> > (How come no one ever does this?  As developers don't we all have to
> > read bug reports, and don't you always want to know which version the
> > bug is reported against?)
> >
> > -jh-
> 
> --
>                                   ------------
> 
>  - The happiest of people aren't the ones
>    who always have the best of everything;
>    they are the ones who always make the best
>    of everything they have.
> 
>                                            Ed Morehouse
>                                            Software Engineer/Evil Genius
>                                            The Motley Fool
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org

From k_svanberg at yahoo.se  Wed Sep  6 12:30:56 2000
From: k_svanberg at yahoo.se (=?iso-8859-1?q?Kennet=20Svanberg?=)
Date: Fri Aug  6 17:04:48 2004
Subject: [jdom-interest] (no subject)
Message-ID: <20000906193056.11554.qmail@web6304.mail.yahoo.com>

Hi all,
have I understood the code in XMLOutputter correct:
if the following document would be output, the line
starting with <!ENTITY would NOT be printed but
everthing else?
Is this made on purpose? would it be useful to have a
setXXX to include/suppress this part of the document.
Or am I possibly the only one still using DTDs...

<?xml version="1.0" ?>
<!DOCTYPE nodes SYSTEM "http://127.0.0.1:8080" [
<!ENTITY pics SYSTEM "../pics/pic.gif" >
]>
<nodes>
	<node>Some content</node>
	<graphics name="pics"/>
	<othernode>Other content</othernode>
</nodes>

-Kennet Svanberg

_____________________________________________________
Do You Yahoo!?
Ditt_namn@yahoo.se - skaffa en gratis mailadress p? http://mail.yahoo.se

From brett.mclaughlin at lutris.com  Wed Sep  6 20:23:26 2000
From: brett.mclaughlin at lutris.com (Brett McLaughlin)
Date: Fri Aug  6 17:04:48 2004
Subject: [jdom-interest] builders not preserving namespace attributes in xsl 
 files
References: <39B6967E.48DE0C32@fool.com> <39B6BBD1.E995D763@collab.net> <39B6CC9A.D3DFCE20@fool.com> <39B6DDC6.31F2EA2@lutris.com> <39B6FC95.A87C7450@fool.com>
Message-ID: <39B70A2E.D3B8F431@lutris.com>


Ed Morehouse wrote:
> 
> Thank you.  If you don't mind, i would be grateful if you would send me a brief
> description of the cause of the bug once you've fixed it.  I spent a good hour
> wading through DOMBuilder.buildTree(), which seemed to me to be the most likely
> locus of such a thing, but i came away feeling unenlightened, and began to
> suspect that the problem might be somewhere in xerces (especially when i saw
> that SAXBuilder did the same thing).  I wouldn't mind getting my hands dirty
> with jdom, and i imagine that you prefer patches to bug reports, so any
> description you would care to offer might help us both.

No problem. The error is tied to the fact that for each Element in JDOM,
that Element has a Namespace object tied to it (even if the Namespace is
the NO_NAMESPACE object). However, there is no means of adding namespace
declarations for namespaces that are not intrinsic to the Element. So in
your example, the XSL namespace is picked up, because it is tied to the
element called stylesheet, in the XSL namespace. However, since the foo
and JavaXML prefixed namespaces are never tied to a specific Element,
they are never dealt with. In essence, there is no
addNamespaceDeclaration() method available for objects. 

What you see in SAXBuilder and DOMBuilder is that the namespace
declarations /are/ being reported correctly (thus, there is no bug with
Xerces), but they are essentially ignored if they aren't on an Element.
For example, in SAXBuilder, we actually turn off namespace processing,
and thus all namespaces are reported as attributes (we are more
efficient this way); we even capture each Namespace in the characters()
callback:

            if (attName.startsWith("xmlns")) {
                int attributeSplit;
                String prefix = "";
                String uri = atts.getValue(i);
                Namespace ns = null;
                if ((attributeSplit = attName.indexOf(":")) != -1) {
                    prefix = attName.substring(attributeSplit + 1);
                }

                // Add namespace to list
                ns = Namespace.getNamespace(prefix, uri);
                elementDefinitions.add(ns);
                namespaces.add(ns);
            }
        }

        // Add this element and its definitions to the global mapping
map
        namespaceDefinitions.put(rawName, elementDefinitions);

The problem is that other than when the Element is created:

        Element element =
            new Element(name, prefix, getNamespaceURI(prefix));

there is no means of adding these other Namespaces to the element's
declaration.

The fix, essentially, would be to add (back - we used to have this)
something like:

addNamespaceDeclaration(Namespace ns)

onto the Element. We could then add these additional declarations to the
Element, and it would be easy enough to print them out at the
XMLOutputter level. Each Element, then, would presumably have a HashMap
of declarations on it (other than the one that is intrinsic to it).

You can take a look at this if you like - I'm bogged down, so the more
help the merrier.

> 
> Sorry again for the sloppy bug reporting. I promise i will be more precise in
> the future.

Actually, it wasn't a big deal - I got your problem mixed up with
Elliotte fixing disparate prefixes, so that was a lot of the confusion.

-Brett

> 
> -Ed
> 
> Brett McLaughlin wrote:
> > Yep, it's a bug. I'll work on it tonight or tomorrow...
> >
> > -Brett
> 
>                                   ------------
> 
>  - The happiest of people aren't the ones
>    who always have the best of everything;
>    they are the ones who always make the best
>    of everything they have.
> 
>                                            Ed Morehouse
>                                            Software Engineer/Evil Genius
>                                            The Motley Fool

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org

From jozart at csi.com  Thu Sep  7 05:03:59 2000
From: jozart at csi.com (Joseph Bowbeer)
Date: Fri Aug  6 17:04:48 2004
Subject: [jdom-interest] Re: jdom-interest digest, Vol 1 #206 - 24 msgs
References: <200009062329.RAA14398@dorothy.denveronline.net>
Message-ID: <030501c018c3$b51d9cc0$5c8a7cce@REPLICANT>

Date: Wed, 06 Sep 2000 15:12:20 -0700
From: Jason Hunter <jhunter@collab.net>
To: "Galluzzo, Eric" <EGalluzzo@synchrony.net>
CC: "'jdom-interest@jdom.org'" <jdom-interest@jdom.org>
Subject: Re: [jdom-interest] Patch to build.xml

> > Trying to build with JDK 1.1 ...
> >
>
> Good catch.  Set and HashSet are now used in
> XMLOutputter, so JDK 1.1 needs more replace rules.
>
> We could add all 20 some replace options but that
> just slows down the build.  We could also go to using
> java.util.* instead of explicit declaration per class;
> that'd mean we only need one replace rule.
>

I think explicit imports are the best solution (and are a good idea
anyway).

There are 29 classes in the Collections compatibility package.

 http://java.sun.com/beans/infobus/collectionsreadme.html

Some of the replacement classes replace classes that are not in
java.util, and some of the classes in java.util (e.g., StringTokenizer)
are not in this package.

The two most common sticklers, by the way, are Comparable and
UnsupportedOperationException. These are included in JDK1.1 Collections,
but because they're part of java.lang in Java2, they aren't usually
imported explicitly in the source code.

--
Joe Bowbeer





From elharo at metalab.unc.edu  Thu Sep  7 05:20:43 2000
From: elharo at metalab.unc.edu (Elliotte Rusty Harold)
Date: Fri Aug  6 17:04:48 2004
Subject: [jdom-interest] Accessing Child Elements
In-Reply-To: <704ECFDA88B3D311B5F000A0C959E5B601FBBB@adobo.c2labs.com>
References: <704ECFDA88B3D311B5F000A0C959E5B601FBBB@adobo.c2labs.com>
Message-ID: <p04330102b5dd3501336e@[168.100.203.234]>

I think the current behavior of JDOM with respect to namespaces is 
correct and should not be changed. I am categorically opposed to ALL 
the proposals that have been made in this thread. It is NOT true that 
you can assume that a child element shares the namespace of its 
parent. RDF and XSLT are just two common XML applications where this 
assumption is very frequently violated.

A large part of the issue is that, unlike DOM, JDOM allows elements 
to exist and be moved and copied and so forth independent of a 
document or context. To allow namespaces to be context dependent 
would mean that an element could change from an RDF set element to an 
SVG set element to a MathML set element simply depending on where it 
was put. This is not what users need or want.

I understand not all the proposals involve context dependent 
namespaces. Some simply want a request for children to assume the 
namespace of the parent. However, I still don't like this. In the 
general case, I may not know the namespace of the parent. For 
instance, I could be walking a document tree looking for all svg 
elements in the http://www.svg.org/ namespace. I don't know where 
those will show up. Or looking for all title elements with no 
namespace. In either case I should ask for exactly what I want. I 
think making the behavior of the getChild(String name) method 
dependent on the namespace of the parent element will be confusing 
for many users and cause unexpected bugs.

I think the current approach is simpler, more intuitive, easier to 
explain and easier to learn. This is,

1. An unprefixed name with a URI is always in the default namespace.
2. An unprefixed name without a URI is always in no namespace.
3. A prefixed name is always in whatever namespace the URI specifies.

Note that these rules are true for ALL methods in ALL classes. There 
are no special cases, or instances where the rules change depending 
on which method you're calling. This is consistent, and therefore 
easy to learn and easy to use. What's being proposed is much less 
consistent, much less easy to learn, and much less easy to use.

I do think there are some current problems with our namespace 
implementation--allowing namespace declarations for attribute values 
for the most part--but those are all orthogonal to what's being 
discussed in this thread.
-- 

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
|                  The XML Bible (IDG Books, 1999)                   |
|              http://metalab.unc.edu/xml/books/bible/               |
|   http://www.amazon.com/exec/obidos/ISBN=0764532367/cafeaulaitA/   |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://metalab.unc.edu/javafaq/ |
|  Read Cafe con Leche for XML News: http://metalab.unc.edu/xml/     |
+----------------------------------+---------------------------------+

From elharo at metalab.unc.edu  Thu Sep  7 05:41:12 2000
From: elharo at metalab.unc.edu (Elliotte Rusty Harold)
Date: Fri Aug  6 17:04:48 2004
Subject: [jdom-interest] builders not preserving namespace attributes
 in xsl   files
In-Reply-To: <39B70A2E.D3B8F431@lutris.com>
References: <39B6967E.48DE0C32@fool.com> <39B6BBD1.E995D763@collab.net>
 <39B6CC9A.D3DFCE20@fool.com> <39B6DDC6.31F2EA2@lutris.com>
 <39B6FC95.A87C7450@fool.com> <39B70A2E.D3B8F431@lutris.com>
Message-ID: <p04330106b5dd3cc4063c@[168.100.203.234]>

At 10:23 PM -0500 9/6/00, Brett McLaughlin wrote:

>The fix, essentially, would be to add (back - we used to have this)
>something like:
>
>addNamespaceDeclaration(Namespace ns)
>
>onto the Element. We could then add these additional declarations to the
>Element, and it would be easy enough to print them out at the
>XMLOutputter level. Each Element, then, would presumably have a HashMap
>of declarations on it (other than the one that is intrinsic to it).
>
>You can take a look at this if you like - I'm bogged down, so the more
>help the merrier.
>

I am thinking about this problem, and will try to take a stab at 
fixing it (and several related problems) this weekend. I'm not 
familiar with the builder code so it may take me a while. However, 
the trickiest part is getting the internal model right. We need to 
allow arbitrary namespace declarations on arbitrary elements, and we 
may need to maintain their locations. That's going to be tough given 
how the code is structured currently.
-- 

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
|                  The XML Bible (IDG Books, 1999)                   |
|              http://metalab.unc.edu/xml/books/bible/               |
|   http://www.amazon.com/exec/obidos/ISBN=0764532367/cafeaulaitA/   |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://metalab.unc.edu/javafaq/ |
|  Read Cafe con Leche for XML News: http://metalab.unc.edu/xml/     |
+----------------------------------+---------------------------------+

From dillo at lethe.ch  Thu Sep  7 06:21:25 2000
From: dillo at lethe.ch (Oliver Dill)
Date: Fri Aug  6 17:04:48 2004
Subject: [jdom-interest] com.sun.java.util.collections.NoSuchElementException
Message-ID: <00a801c018ce$8810b5e0$0500a8c0@LocalHost>

Hello all

I've got a exception in the Java 1.1 environment that sounds strange
to me: I compiled a JDOM (todays cvs) build for Java 1.1 in my Java 1.2
environment and it works fine on my Win95 Box. I uploaded the build
to the webserver. My ISP runs Java 1.1.7 and has the collections.jar
installed. Now, the fellowing servlet gives a
com.sun.java.util.collections.NoSuchElementException:

<servlet>
[...]
Element root = new Element("return");
root.setText("no exception!");
Document doc = new Document(root);
XMLOutputter outputter = new XMLOutputter();
outputter.output(doc, out);
[...]
</servlet>


<Exception>
com.sun.java.util.collections.NoSuchElementException
at com.sun.java.util.collections.LinkedList.getLast(LinkedList.java:106)
at org.jdom.PartialList.addLast(PartialList.java:169)
at org.jdom.PartialList.add(PartialList.java:364)
at com.sun.java.util.collections.AbstractList.add(AbstractList.java:78)
at org.jdom.PartialList.addPartial(PartialList.java:411)
at org.jdom.PartialList.addAllPartial(PartialList.java:424)
at org.jdom.Element.getMixedContent(Element.java:621)
at org.jdom.output.XMLOutputter.printElement(XMLOutputter.java:519)
at org.jdom.output.XMLOutputter.printElement(XMLOutputter.java:502)
at org.jdom.output.XMLOutputter.output(XMLOutputter.java:329)
at helloxml.sendXMLFile(helloxml.java:172)
at helloxml.service(helloxml.java:40)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:588)
at org.apache.jserv.JServConnection.processRequest(JServConnection.java:314)
at org.apache.jserv.JServConnection.run(JServConnection.java:188)
at java.lang.Thread.run(Thread.java)
</Exception>


Has anyone an idea what happend?

Oliver




From pvg at c-c-s.com  Thu Sep  7 08:41:50 2000
From: pvg at c-c-s.com (Peter V. Gadjokov)
Date: Fri Aug  6 17:04:49 2004
Subject: [jdom-interest] Accessing Child Elements
Message-ID: <704ECFDA88B3D311B5F000A0C959E5B601FBC1@adobo.c2labs.com>

 <<>> 
Ellioette wrote:

>I think the current behavior of JDOM with respect to namespaces is 
>correct and should not be changed. I am categorically opposed to ALL 
>the proposals that have been made in this thread. 

Well, I categorically disagree with the notion that the current
implementation is 'correct' but then again, that's why we're having
this discussion. Nevertheless, I'm finding the word 'categorically' a
little strong given the rather minimal changes in my last proposal. :)

>It is NOT true that you can assume that a child element shares the
>namespace of its parent. RDF and XSLT are just two common XML
>applications where this assumption is very frequently violated.

It is no more true (and I think a lot less practically useful) that
one can assume the child is in the empty namespace. I was proposing a
change to what, in either implementation, is a convenience method, not
an 'intrinsic' one. By convenience method I mean a method that is
implemented in terms of other public methods, whether convienience
methods or intrinsic ones. By this definition, all convenience methods
can be reduced to a set of intrinsic ones. We can argue back and forth
forever about which operation is more common - retrieval of an element
in the empty namespace or retrieval of an element in the parent's
namespace. The fact is, both implementations of the convenience methods
_have_ to make _some_ assumption.

From brett.mclaughlin at lutris.com  Thu Sep  7 09:24:23 2000
From: brett.mclaughlin at lutris.com (Brett McLaughlin)
Date: Fri Aug  6 17:04:49 2004
Subject: [jdom-interest] Accessing Child Elements
References: <704ECFDA88B3D311B5F000A0C959E5B601FBBB@adobo.c2labs.com> <p04330102b5dd3501336e@[168.100.203.234]>
Message-ID: <39B7C137.8766E207@lutris.com>


Elliotte Rusty Harold wrote:
> 
> I think the current behavior of JDOM with respect to namespaces is
> correct and should not be changed. I am categorically opposed to ALL
> the proposals that have been made in this thread. It is NOT true that
> you can assume that a child element shares the namespace of its
> parent. RDF and XSLT are just two common XML applications where this
> assumption is very frequently violated.
> 
> A large part of the issue is that, unlike DOM, JDOM allows elements
> to exist and be moved and copied and so forth independent of a
> document or context. To allow namespaces to be context dependent
> would mean that an element could change from an RDF set element to an
> SVG set element to a MathML set element simply depending on where it
> was put. This is not what users need or want.
> 
> I understand not all the proposals involve context dependent
> namespaces. Some simply want a request for children to assume the
> namespace of the parent. However, I still don't like this. In the
> general case, I may not know the namespace of the parent. For
> instance, I could be walking a document tree looking for all svg
> elements in the http://www.svg.org/ namespace. I don't know where
> those will show up. Or looking for all title elements with no
> namespace. In either case I should ask for exactly what I want. I
> think making the behavior of the getChild(String name) method
> dependent on the namespace of the parent element will be confusing
> for many users and cause unexpected bugs.
> 
> I think the current approach is simpler, more intuitive, easier to
> explain and easier to learn. This is,
> 
> 1. An unprefixed name with a URI is always in the default namespace.
> 2. An unprefixed name without a URI is always in no namespace.
> 3. A prefixed name is always in whatever namespace the URI specifies.
> 
> Note that these rules are true for ALL methods in ALL classes. There
> are no special cases, or instances where the rules change depending
> on which method you're calling. This is consistent, and therefore
> easy to learn and easy to use. What's being proposed is much less
> consistent, much less easy to learn, and much less easy to use.
> 
> I do think there are some current problems with our namespace
> implementation--allowing namespace declarations for attribute values
> for the most part--but those are all orthogonal to what's being
> discussed in this thread.

For the record, I'm also in agreement with Elliotte - he laid the
reasons out very well, so I'll just say I agree ;-)

-Brett

> --
> 
> +-----------------------+------------------------+-------------------+
> | Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
> +-----------------------+------------------------+-------------------+
> |                  The XML Bible (IDG Books, 1999)                   |
> |              http://metalab.unc.edu/xml/books/bible/               |
> |   http://www.amazon.com/exec/obidos/ISBN=0764532367/cafeaulaitA/   |
> +----------------------------------+---------------------------------+
> |  Read Cafe au Lait for Java News:  http://metalab.unc.edu/javafaq/ |
> |  Read Cafe con Leche for XML News: http://metalab.unc.edu/xml/     |
> +----------------------------------+---------------------------------+
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org

From QGuo at Emptoris.com  Thu Sep  7 09:57:56 2000
From: QGuo at Emptoris.com (Guo, Quanzhong)
Date: Fri Aug  6 17:04:49 2004
Subject: [jdom-interest] memory consumption - JDOM vs. DOM
Message-ID: <15717BB71A5CD411A01600508BDCC2E2120746@EMPBUREXCH>

Hi I am new on JDOM, I have a question regarding JDOM memory consumptiom. I
wrote 2 JAVA applications on NT, one uses Xerces/DOM, one uses JDOM through
Xerces/SAX, they both do virtually the same thing: load a large XML file
into memory. I got the following results. Looks like JDOM consistently uses
more memory than Xerces/DOM does. Could anyone give me some idea what was
wrong?

Thanks,
quan

----------------------------------------------------------------------------
--------------------------------------------

With 64M memory for the JAVA VM:

XMl File size		Xerces/DOM			JDOM
----------------------------------------------------------------------------
--------------------------------------------
7.3M			Succeed			Succeed
8.0M			Succeed			OutOfMemory Exception
9.2M			Succeed			OutOfMemory Exception
9.8M			OutOfMemory Exception		OutOfMemory
Exception
----------------------------------------------------------------------------
--------------------------------------------

With 128M memory for the JAVA VM:

XML File size		Xerces/DOM			JDOM
----------------------------------------------------------------------------
--------------------------------------------
15.3M			Succeed			Succeed
16.6M			Succeed			OutOfMemory Exception
----------------------------------------------------------------------------
--------------------------------------------


From philion at acmerocket.com  Thu Sep  7 10:23:37 2000
From: philion at acmerocket.com (Paul Philion)
Date: Fri Aug  6 17:04:49 2004
Subject: [jdom-interest] Why not interfaces?
Message-ID: <GEEIKGLIDNNEIBDLFCAMOEJLDDAA.philion@acmerocket.com>

Greetings -

I've just been looking over the JDOM docs and APIs and I noticed that
all the major classes were concrete classes, not interfaces with
supporting abstract implementations.

As most of the parsing work is handled with the Builder classes, which
are pretty much factories, why not use interfaces for a more flexible
design?

Perhaps I missed a whole discussion of this, and someone could kindly
point me to the list archive.

Thanks,

- Paul Philion


From jhunter at collab.net  Thu Sep  7 10:38:18 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:04:49 2004
Subject: [jdom-interest] Why not interfaces?
References: <GEEIKGLIDNNEIBDLFCAMOEJLDDAA.philion@acmerocket.com>
Message-ID: <39B7D28A.C4388C79@collab.net>

> I've just been looking over the JDOM docs and APIs and I noticed that
> all the major classes were concrete classes, not interfaces with
> supporting abstract implementations.

I just posted recently about the things that the interface/factory makes
you do, as evidenced by what DOM does.  Think about building a "thread
safe" implementation -- then how do you guarantee the doc remains thread
safe?  You have to do things like use the doc as the factory and import
nodes.  Way more pain than it's worth.  You also lose the ability to
mandate how equals() works, and things like that.

-jh-

P.S.  So we meet again Paul.  :-)

From philion at acmerocket.com  Thu Sep  7 12:20:23 2000
From: philion at acmerocket.com (Paul Philion)
Date: Fri Aug  6 17:04:49 2004
Subject: [jdom-interest] Why not interfaces?
In-Reply-To: <39B7D28A.C4388C79@collab.net>
Message-ID: <GEEIKGLIDNNEIBDLFCAMIEKBDDAA.philion@acmerocket.com>

I've added comments below, inline...

-jh- said:
> I just posted recently about the things that the
> interface/factory makes you do, as evidenced by
> what DOM does.

I missed the original. Is there somewhere I can review it online? I
don't want to rehash a discussion that has already been had.

> Think about building a "thread safe" implementation
> -- then how do you guarantee the doc remains thread
> safe?  You have to do things like use the doc as the
> factory and import nodes.  Way more pain than it's worth.
> You also lose the ability to mandate how equals() works,
> and things like that.

You mention two issues here:

1) Making the Document thread-safe.

- Looking over the latest code, Document is not thread-safe. I would
recommend a solution similar to the one offered by the Java 1.1
collections. Have a "standard" implementation that is *not*
thread-safe, and a method on the Document builder that is
"buildSynchronized", that wraps a synchronized wrapper around the
document.

2) Mandating how equals is handled.

- One suggestion is to have a static utility method to compare to two
Documents. The "standard" implementation would use this. Novel
implementations of the Document (if it was an interface) could also
use it.

I'm sure that you covered this, and other issues in your recent post.
I'd really like to read it before I step in it too deeply.

> P.S.  So we meet again Paul.  :-)

Hell, I've been around... You've just been too busy to notice. ;^)

- Paul



From pvg at c-c-s.com  Thu Sep  7 12:54:20 2000
From: pvg at c-c-s.com (Peter V. Gadjokov)
Date: Fri Aug  6 17:04:49 2004
Subject: [jdom-interest] Accessing Child Elements
Message-ID: <704ECFDA88B3D311B5F000A0C959E5B601FBC2@adobo.c2labs.com>

Wrote Brett
 
>For the record, I'm also in agreement with Elliotte - he laid the
>reasons out very well, so I'll just say I agree ;-)

Fair enough, although my understanding of Elliotte's reasons is not as
clear as yours yet. Elliotte has said that
       - having getChild return anything other than a child in the
         empty namespace is confusing.
       - there is a set of simple rules that describes
         the behaviour of all methods create/find methods involving
         names and namespaces.

On the first item, I don't see how that method is less confusing and
even if it was (hard to distinguish between confusing to me or
Ellioette and 'objectively confusing'...), the 'non-confusing' method
seems useless and impractical to me. I don't see how one would have a
reason to call it often if namespaces were in use.

As to the rules they are:

1. An unprefixed name with a URI is always in the default namespace. 
2. An unprefixed name without a URI is always in no namespace. 
3. A prefixed name is always in whatever namespace the URI specifies. 

Concise, granted but easy and intuitive? I don't see the notion of a
prefixed or unprefixed names being directly represented in the core
API - certainly every method on Element that has anything to do with
names (besides getQualifiedName) deals with local names, always. To
apply the rules, a user has to know the precise state of the
parameters being passed in to something like
getChild("name", namespace). Additionally, you need to know what
prefixes are and how they behave and that there is, for instance, such
a thing as a 'default' namespace which, as far as the Java API user is
concerned, is the same namespace as any other namespace with the same
URI except it's different. Suppose then you hit the namespace spec and
figured out exactly how it's different. You find out that in textually
represented XML, if an element declares a namespace with a URI and no
prefix, any child elements without a prefixed name or default
namespace declaration of its own belongs to the namespace of the
enclosing element. Ah, you say, so prefixes and namespaces are there
so my JDOM tree looks and acts like an XML tree! You create a new
element, with an _unprefixed_ name and no namespace, you add it to the
parent and what do you get? A child in the empty namespace. Sure,
that's what the rule says but that's not the rule you just saw in the
Namespace spec. Easy to learn though, no?

I'm not suggesting the 'dynamic' behaviour should be implemented as
described above - I'm hoping to illustrate that the ruleset is
anything but intuitive and easy to learn and that familiarity and habit
do not always constitute simplicity. The simple changes I proposed are
of essentially equivalent (high) complexity, give or take some delta
for taste. The difference is that I wanted the notion of a default
namespace effectively removed (and coalescing namespace declarations
to default or otherwise to be done during output) and the default
behaviour of getChild and co to do something useful when namespaces
are in use - this also lays the groundwork for banishing the whole
prefix mess from the core model.

Now, I'm perfectly happy to accept that Ellioette doesn't like this
change because it doesn't appeal to him aesthetically, it seems oddly
unfamiliar, or he has an experience-based gut-feeling that is likely
correct but hasn't fully bubbled up to concious verbalization. These
might not be great strictly technical reasons but they are reasons
nonetheless - APIs are designed, implemented and used  by people,
after all. But given the overwhelming complexity of namespace/prefix
handling in the current implementation, I find it difficult to accept
that a couple of fairly small, in the grand scheme of things, changes
make the whole thing 'categorically' wrong and unintuitive - not 
without some more concrete justification of the more intuitive and
useful nature of the existing behaviour.

In any event, I think I've ranted on this matter long enough. JDOM works
and is useful to me right now, as it is. I do think we are missing an
oppurtunity to do something well in line with the 'JDOM Philosophy',
as stated in the FAQ:

[...] JDOM should hide the complexities of XML wherever possible, while
remaining true to the XML specification [...]

I'll take working code over philosophy any day though.

Thanks,

-pvg

From mengelhart at earthtrip.com  Thu Sep  7 14:11:27 2000
From: mengelhart at earthtrip.com (Michael Engelhart)
Date: Fri Aug  6 17:04:49 2004
Subject: [jdom-interest] getAttributeValue() removing escaped char
Message-ID: <0388d0609210790SM2@Mail.austin.rr.com>

Hi,

I have simple XML file with elements like this:

<resource key="REGEX" value="m/[a-z].*\\W+/s" />


when I read it in and call Element.getAttributeValue("value"), I get this  
as the string:
m/[a-z].*\W+/s

where the original has an escaped "\\" in it:
m/[a-z].*\\W+/s

Any idea what gives?

Thanks,

Mike

From jhunter at collab.net  Thu Sep  7 14:29:10 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:04:49 2004
Subject: [jdom-interest] Why not interfaces?
References: <GEEIKGLIDNNEIBDLFCAMIEKBDDAA.philion@acmerocket.com>
Message-ID: <39B808A6.F5F31159@collab.net>

> I missed the original. Is there somewhere I can review it online? I
> don't want to rehash a discussion that has already been had.

The archives are online via the link from the web site.  Not easy to
search except download a month and CTRL-F but it gets the job done.

> 1) Making the Document thread-safe.
> 
> - Looking over the latest code, Document is not thread-safe. I would
> recommend a solution similar to the one offered by the Java 1.1
> collections. Have a "standard" implementation that is *not*
> thread-safe, and a method on the Document builder that is
> "buildSynchronized", that wraps a synchronized wrapper around the
> document.

The FAQ addresses this.  We leave it to the programmer because we can't
do much thread safety within the class, most has to be external, so we
let all be external.

> 2) Mandating how equals is handled.
> 
> - One suggestion is to have a static utility method to compare to two
> Documents. The "standard" implementation would use this. Novel
> implementations of the Document (if it was an interface) could also
> use it.
> 
> I'm sure that you covered this, and other issues in your recent post.
> I'd really like to read it before I step in it too deeply.

I didn't write all *that much* about it because I know interfaces aren't
something we're willing to switch (back) to.  We actuall started with
interfaces in our private impls before going public, and believe me we
were MUCH happier about the design with concrete classes.

-jh-

From brett.mclaughlin at lutris.com  Thu Sep  7 14:43:01 2000
From: brett.mclaughlin at lutris.com (Brett McLaughlin)
Date: Fri Aug  6 17:04:49 2004
Subject: [jdom-interest] Accessing Child Elements
References: <704ECFDA88B3D311B5F000A0C959E5B601FBC2@adobo.c2labs.com>
Message-ID: <39B80BE5.476F3932@lutris.com>


"Peter V. Gadjokov" wrote:
> 
> Wrote Brett
> 
> >For the record, I'm also in agreement with Elliotte - he laid the
> >reasons out very well, so I'll just say I agree ;-)
> 
> Fair enough, although my understanding of Elliotte's reasons is not as
> clear as yours yet. Elliotte has said that
>        - having getChild return anything other than a child in the
>          empty namespace is confusing.

No, he's said that it is confusing in light of the XML Namespace
specification, which I think is different.

First, we have no constructor that absorbs its parent's namespace, which
means a getChild that took that into account would begin to build
non-uniformity into our method behaviors.

Second, it is clear from the XML Namespace rec that a namespace is
intrinsic to an Element; although it may make sense for an Element to be
referenced implicitly by it's parent namespace, it is wrong in regards
to the spec, and thus I don't like to encourage it.

Third, it is not at all unusual for the default namespace, and the no
namespace, to be used. Almost every XSLT document around uses both. So
your claim that they aren't common uses is way off. XHTML has the same
case.

>        - there is a set of simple rules that describes
>          the behaviour of all methods create/find methods involving
>          names and namespaces.
> 
> On the first item, I don't see how that method is less confusing and
> even if it was (hard to distinguish between confusing to me or
> Ellioette and 'objectively confusing'...), the 'non-confusing' method
> seems useless and impractical to me. I don't see how one would have a
> reason to call it often if namespaces were in use.

All the time. XSLT, SVG, and XML Schemas are two very common cases where
I'm constantly having children in a different namespace than the parent.
Well designed XSLT templates require this.

> 
> As to the rules they are:
> 
> 1. An unprefixed name with a URI is always in the default namespace.
> 2. An unprefixed name without a URI is always in no namespace.
> 3. A prefixed name is always in whatever namespace the URI specifies.
> 
> Concise, granted but easy and intuitive? I don't see the notion of a

I think so, given an understanding of the XML Namespace spec. YOu have
to remember, we are intuitive as long as that intuitiveness is correct.
We went through this a long time ago - if something is intuitive but
WRONG, we won't put it in; we don't encourage bad use-patterns. That's
why getText() no longer returns trimmed content. People expected it, but
they were WRONG, so we made sure to make them be right.

> prefixed or unprefixed names being directly represented in the core
> API - certainly every method on Element that has anything to do with
> names (besides getQualifiedName) deals with local names, always. To

Not true - it deals with local names AND a Namespace. There is never a
use in the core of a local name along (even when it's only a local name
passed in, a Namespace object is added and that's how the Element is
dealt with). It's always a local name and Namespace.

> apply the rules, a user has to know the precise state of the
> parameters being passed in to something like
> getChild("name", namespace). Additionally, you need to know what

In your methodology, they have to know the precise state of the
document. I'd rather be exact and verbose on a single element and have
the Element be indpendent of the condition of its surroundings. That's
safe, and good programming. To depend on the surroundings being a
certain way is a bad idea.

> prefixes are and how they behave and that there is, for instance, such
> a thing as a 'default' namespace which, as far as the Java API user is
> concerned, is the same namespace as any other namespace with the same
> URI except it's different. Suppose then you hit the namespace spec and
> figured out exactly how it's different. You find out that in textually
> represented XML, if an element declares a namespace with a URI and no
> prefix, any child elements without a prefixed name or default
> namespace declaration of its own belongs to the namespace of the
> enclosing element. Ah, you say, so prefixes and namespaces are there
> so my JDOM tree looks and acts like an XML tree! You create a new
> element, with an _unprefixed_ name and no namespace, you add it to the
> parent and what do you get? A child in the empty namespace. Sure,
> that's what the rule says but that's not the rule you just saw in the
> Namespace spec. Easy to learn though, no?

I don't think so - that assumes the user blindly used JDOM without ever
bothering to read an email or Javadocs. We can't help that kind of user.
We can help the one that read that spec, read the Javadocs quickly, and
understands that for the same reason, we make sure that each Element has
its namespace specified, to avoid confusion. In your case, literally
changing the order of the tree being built changes the namespace. 

Element parent = new Element("parent", myNamespace);
parent.addChild(new Element("child"));

is not the same as

Element child = new Element("child");
Element parent = new Element("parent", myNamespace);
parent.addChild(child);

Unless you change the whole API. That's a very confusing situation! I
think if you add getChild(), you have to change addChild(), and on down
the line... feels like a slippery slope.

> 
> I'm not suggesting the 'dynamic' behaviour should be implemented as
> described above - I'm hoping to illustrate that the ruleset is
> anything but intuitive and easy to learn and that familiarity and habit
> do not always constitute simplicity. The simple changes I proposed are
> of essentially equivalent (high) complexity, give or take some delta
> for taste. The difference is that I wanted the notion of a default
> namespace effectively removed (and coalescing namespace declarations
> to default or otherwise to be done during output) and the default

Why? By definition, that really blows out a major component of the
specification. I actually really like default namespaces, as they make
life... well... easy...

> behaviour of getChild and co to do something useful when namespaces
> are in use - this also lays the groundwork for banishing the whole
> prefix mess from the core model.

Again, though, prefixes are an intrinsic part of XML Namespaces. Or did
I misunderstand you here?

> 
> Now, I'm perfectly happy to accept that Ellioette doesn't like this
> change because it doesn't appeal to him aesthetically, it seems oddly
> unfamiliar, or he has an experience-based gut-feeling that is likely
> correct but hasn't fully bubbled up to concious verbalization. These

To me, it's non XML Namespaces-compliant, promotes incorrect
understandings of the XML Namespaces spec, and is prone to cause
unpredictable results. I can't speak for Elliotte ;-)

> might not be great strictly technical reasons but they are reasons
> nonetheless - APIs are designed, implemented and used  by people,
> after all. But given the overwhelming complexity of namespace/prefix
> handling in the current implementation, I find it difficult to accept

I think you are exaggerating here - what is so complex about it? In my
book, I use namespaces in every example, and have not received a single
question on them - and I get a ton of questions!

> that a couple of fairly small, in the grand scheme of things, changes
> make the whole thing 'categorically' wrong and unintuitive - not
> without some more concrete justification of the more intuitive and
> useful nature of the existing behaviour.
> 
> In any event, I think I've ranted on this matter long enough. JDOM works
> and is useful to me right now, as it is. I do think we are missing an
> oppurtunity to do something well in line with the 'JDOM Philosophy',
> as stated in the FAQ:
> 
> [...] JDOM should hide the complexities of XML wherever possible, while
> remaining true to the XML specification [...]
> 
> I'll take working code over philosophy any day though.

I think you brought out a good FAQ - but I maintain (and I think
Elliotte does too) that this change wouldn't remain true to the spec.

In any case, good discussions, let's keep at it ;-)

-Brett

> 
> Thanks,
> 
> -pvg

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org

From jhunter at collab.net  Thu Sep  7 15:08:13 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:04:49 2004
Subject: [jdom-interest] memory consumption - JDOM vs. DOM
References: <15717BB71A5CD411A01600508BDCC2E2120746@EMPBUREXCH>
Message-ID: <39B811CD.E03B2209@collab.net>

> Hi I am new on JDOM, I have a question regarding JDOM memory 
> consumptiom. I  wrote 2 JAVA applications on NT, one uses 
> Xerces/DOM, one uses JDOM through Xerces/SAX, they both do 
> virtually the same thing: load a large XML file into memory. 
> I got the following results. Looks like JDOM consistently uses
> more memory than Xerces/DOM does. 
> Could anyone give me some idea what was wrong?

I'm not surprised, we've been defining new functionality for JDOM but
haven't done real memory profiling.  Hopefully you'll be our first
memory profile tester!

I just checked in a change that removes the internal text caching
behavior.  This should significantly reduce the memory consumption and
also save us from the need to synchronize the cache logic manipulation
-- something that's necessary even for single-thread use because of that
strange Java "bug" as was discussed earlier on the list.

I also added an optimization to getText() for when the content is a
single String (now it just returns that string), and this should speed
up things like outputting because it avoids duplicating the string with
a string buffer.  That was just a little low-hanging fruit...

Anyway, Q, please run your tests again with the latest from CVS and post
if my change helped any.

-jh-

From jhunter at collab.net  Thu Sep  7 15:42:52 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:04:49 2004
Subject: [jdom-interest] Re: jdom-interest digest, Vol 1 #206 - 24 msgs
References: <200009062329.RAA14398@dorothy.denveronline.net> <030501c018c3$b51d9cc0$5c8a7cce@REPLICANT>
Message-ID: <39B819EC.D1396E26@collab.net>

> I think explicit imports are the best solution (and are a good idea
> anyway).

I personally find them a pain in the neck.  They cause more failed
compiles during development (a real pain on the slow laptop I use). 
Plus the use of explicit imports hid the NoSuchElementException
collision we had earlier.

(Brett prefers explicits.)

-jh-

From zeclarks at sprynet.com  Thu Sep  7 17:15:27 2000
From: zeclarks at sprynet.com (Stacie Clark)
Date: Fri Aug  6 17:04:49 2004
Subject: [jdom-interest] xml namespaces
Message-ID: <39B82F9F.EB46CA1C@sprynet.com>

Did the fix for xml:lang and xml:space not make it into CVS?  I just
tested on the latest code in CVS and I got an error.

Stacie Clark


From davidg at arta.com  Thu Sep  7 17:23:36 2000
From: davidg at arta.com (David Geller)
Date: Fri Aug  6 17:04:49 2004
Subject: [jdom-interest] RTFMing didn't work for me
In-Reply-To: <39B819EC.D1396E26@collab.net>
Message-ID: <004b01c0192b$08496610$0464a8c0@snapcap>

A non-text attachment was scrubbed...
Name: smime.p7m
Type: application/x-pkcs7-mime
Size: 5246 bytes
Desc: not available
Url : http://jdom.org/pipermail/jdom-interest/attachments/20000907/95fa77a2/smime.bin
From jhunter at acm.org  Thu Sep  7 18:14:03 2000
From: jhunter at acm.org (Jason Hunter)
Date: Fri Aug  6 17:04:49 2004
Subject: [jdom-interest] xml namespaces
References: <39B82F9F.EB46CA1C@sprynet.com>
Message-ID: <39B83D5B.ABF4196F@acm.org>

 % grep xml:lang *.java
Verifier.java:        // Allow xml:space and xml:lang as special cases
Verifier.java:            name.equals("xml:lang")) {

-jh-

Stacie Clark wrote:
> 
> Did the fix for xml:lang and xml:space not make it into CVS?  I just
> tested on the latest code in CVS and I got an error.
> 
> Stacie Clark
> 
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com

From davidg at arta.com  Thu Sep  7 18:23:14 2000
From: davidg at arta.com (David Geller)
Date: Fri Aug  6 17:04:49 2004
Subject: [jdom-interest] RE: RTFMing didn't work for me
Message-ID: <004f01c01933$5cd78ab0$0464a8c0@snapcap>

A non-text attachment was scrubbed...
Name: smime.p7m
Type: application/x-pkcs7-mime
Size: 5491 bytes
Desc: not available
Url : http://jdom.org/pipermail/jdom-interest/attachments/20000907/4cc4ba99/smime.bin
From brett.mclaughlin at lutris.com  Thu Sep  7 19:04:00 2000
From: brett.mclaughlin at lutris.com (Brett McLaughlin)
Date: Fri Aug  6 17:04:49 2004
Subject: [jdom-interest] RTFMing didn't work for me
References: <004b01c0192b$08496610$0464a8c0@snapcap>
Message-ID: <39B84910.E98189DB@lutris.com>


David Geller wrote:
> 
> I'm trying the simplest of tests to begin learning JDOM (because I need
> to have a small project running within the next few hours!). So I took a
> look at the sample SAXBuilder on page 209 of Brett's book. BTW - the
> Builder interface doesn't appear to be present in JDOM-4. Anyhow...
> 
> I'm on Linux using IBM's Java2-13. I compile the following code
> *successfully* with:
> 
>    javac -classpath ./jdom-b4.jar:./xerces.jar SAXTest.java

Use the latest version from CVS, it should work fine there.

-Brett

> 
> And I try to run it with:
> 
>    java -cp ./jdom-b4.jar:./xerces.jar:. SAXTest test.xml
> 
> and get:
> 
> org.jdom.JDOMException: String index out of range: 0: String index out
> of range: 0
>         at java.lang.Throwable.<init>(Throwable.java:96)
>         at java.lang.Exception.<init>(Exception.java:44)
>         at org.jdom.JDOMException.<init>(JDOMException.java:101)
>         at org.jdom.input.SAXBuilder.build(SAXBuilder.java:229)
>         at org.jdom.input.SAXBuilder.build(SAXBuilder.java:284)
>         at org.jdom.input.SAXBuilder.build(SAXBuilder.java:265)
>         at SAXTest.main(SAXTest.java:22)
> Root cause: java.lang.StringIndexOutOfBoundsException: String index out
> of range: 0
>         at java.lang.Throwable.<init>(Throwable.java:84)
>         at java.lang.Exception.<init>(Exception.java:35)
>         at org.xml.sax.SAXException.<init>(SAXException.java:61)
>         at
> org.apache.xerces.framework.XMLParser.parse(XMLParser.java:834)
>         at org.jdom.input.SAXBuilder.build(SAXBuilder.java:218)
>         at org.jdom.input.SAXBuilder.build(SAXBuilder.java:284)
>         at org.jdom.input.SAXBuilder.build(SAXBuilder.java:265)
>         at SAXTest.main(SAXTest.java:22)
> 
> What am I failing to do/understand? The code, incidentally, is almost
> verbatim from the book - except for the fact that I hardcoded SAXBuilder
> in place of the Builder interface.
> 
> Any help you can provide would be greatly appreciated.
> 
> - David
> 
> Here the test code:
> 
> import java.io.*;
> import org.jdom.Document;
> import org.jdom.Element;
> import org.jdom.JDOMException;
> import org.jdom.input.*;
> 
> public class SAXTest
> {
>         public static void main(String[] args)
>         {
>                 if (args.length != 1)
>                 {
>                         System.out.println ("Usage: SAXTest [filename to
> parse]");
>                         return;
>                 }
> 
>                 try
>                 {
>                         // Build w/ SAX and Xerces, no validation
>                         SAXBuilder b = new SAXBuilder(false);
> 
>                         Document doc = b.build(new File (args[0]));
>                 }
>                 catch (Exception e)
>                 {
>                         e.printStackTrace();
>                 }
>         }
> }

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org

From pvg at c-c-s.com  Thu Sep  7 19:55:06 2000
From: pvg at c-c-s.com (Peter V. Gadjokov)
Date: Fri Aug  6 17:04:49 2004
Subject: [jdom-interest] Accessing Child Elements
Message-ID: <704ECFDA88B3D311B5F000A0C959E5B601FBC3@adobo.c2labs.com>

[pvg]. Elliotte has said that
[pvg]        - having getChild return anything other than a child in the
[pvg]          empty namespace is confusing.

>No, he's said that it is confusing in light of the XML Namespace
>specification, which I think is different.

Yes, it is different - perhaps the confusion arises from the fact that
there were two parallel threads under different subjects on the same
topic. I've mostly been participating in the second one so if
Ellioette was talking about the the namespace _spec_ I must have
simply missed it - the spec is not explicitly mentioned in the email I
was responding to. So let me define how I see the relationship between
JDOM and the namespace (or any XML related-) spec:

    JDOM provides a consistent, simple (as far as possible) OO model
that allows the parsing, manipulation and generation of XML documents
that are always specification compliant. The specs describe both the
general semantics of some feature or facility and its encoded
(serialized) representation - whenever possible, in the interests of
simplicity, JDOM object representation provides identical or
equivalent semantics but _need not_ model details that are entirely in
the realm of the serialized representation. The JDOM _serialization
facilities_ (i.e. facilities that use the object model but are not it)
ensure that correct, spec-compliant XML textual representation can
always be parsed parse and generated. JDOM _guarantees_ spec compliant
serialization/deserialization but the focus of the model is a good,
coherent, simple Java OO API - not a Java representation of every
detail of the spec.

The above is my interpretation of JDOM's philosophy - I'm purposefully
emphasising the Java OO API aspect because I beleieve such APIs are
both higher-level and easier to understand than just about any
XML-related specification. In other words, I see JDOM as a facility
for Java programmers to manipulate and generate compliant XML with
_without highly detailed knowledge of the specs_. JDOM bridges the gap
from Java to XML for those of us who know and write more Java than
XML.

>First, we have no constructor that absorbs its parent's namespace, 
>which means a getChild that took that into account would begin to
>build non-uniformity into our method behaviors.

Again, I'll approach this from the Java/OO standpoint from which, I
believe, there is no non-uniformity. First, a constructor is not a
method. There is indeed no cloning of a parents namespace because
there is no parent. I did propose eliminating the 'name only'
constructor for element as an option. And if my full proposal were
implemented (the representation of expanded element types), there
would be no name-only constructor, the constructor would simply take
an element type object that fully describes and encapsulates the name
and the namespace URI.

>Second, it is clear from the XML Namespace rec that a namespace is
>intrinsic to an Element; although it may make sense for an Element to 
>be referenced implicitly by it's parent namespace, it is wrong in 
>regards to the spec, and thus I don't like to encourage it.

At no time, in my proposal, is an element's namespace ever defined in
terms of it's parent or some other element. Every element has an
intrinsic, immutable namespace which can be queried by the
getNamespace method - conceptually, this represents the spec verbatim.
The namespace spec is about static definition - it does not define or
describe traversal. The getChild method is a traversal method, a
getChild that returns a child from it's parens namespace is both
better and simpler OO behaviour and more practical - and it is a
behaviour outside the scope of the namespace spec. Why is it better
and non-confusing OOP? Some of the comments I've seen almsot seem to
imply that an object using its internal state to 'fill in the blank'
to an underspecified parametrized method call is in itself confusing.
I tend to disagree - this is very much classic OO behaviour -
encapsulation. I'd argue that it's both intuitive and sensible for an
instance to use instance rather than global data in such a case.
Please consider the call outside of the XML context for a moment.
I call a method on an instance and omit an optional parameter: what's
more intuitive:

  - the instance will use instance data to respond to my message,
    giving me the _most specific behaviour possible_
 or
  - the instance will use some global, externally defined constant.

The first is clearly far more sensible OO design - I'm not providing a
piece of external data - but I am calling a specific instance, the
instance is responding in the most instance-specific way possible.
Using an external constant is much more of a 'special case' and
one-off behaviour. It also introduces some additional, unneccessary
coupling - why should an Element object have to know what an empty
namespace is and treat it specially? Under my proposal, an element
treats all namespaces uniformly, there are no distinguished namespaces
at all. The argument is centered on the idea that org.jdom.Element is
not an XML serialized element - an XML serialized element is a data
structure, org.jdom.Element is an object - it makes sense for it to
behave like one and that such behaviour is defined in terms of typical
OO behaviour and not in terms of serialized XML structures as described
by the specification.

>Third, it is not at all unusual for the default namespace, and the no
>namespace, to be used. Almost every XSLT document around uses both. So
>your claim that they aren't common uses is way off. XHTML has the same
>case.

I didn't make any claims regarding the default namespace. When I spoke
of eliminating the defaut namespace I did not mean removing support
for it from serialization and deserialization - I meant hiding the
fact that it exists from the core object model. The default namespace
is what introduces the complex scoping rules which are confusing. Both
the concept of a default namespace and associated scoping are a matter
of the serialized representation - hiding them in the in-memory object
model makes things vastly simpler. One way to look at it is to view
the getNamespace method on Element as the equivalent of an explicit NS
declaration in the XML serialized representation. The getNamespace
method is there on every single element - you don't need to have an
explicit namespace declaration of every element when you serialize but
leave that to the serializer - the API already presents a view of
'explicit annotation', having a default namespace (but no namespace
scoping, like in the XML spec - here the current implementation has no
problem going against the spec, I think correctly) just muddies things
up. As to the empty namespace, no, I don't think it's likely to remain
all that common particularly as all standard and app-specific element
definitions become part of one namespace or another. And we were
discussing a convenience method - nothing in the current
implementation or the proposal prevents you from explicitly retrieving
a child from the empty namespace or a child in a namespace different
than the parent - the implementation of the intrinsic method is
identical in both cases. In my model, the general traversal mechanism
is identical to the current one - it requires an explicit
name/namespace pair. The convenience traversal mechanism is context
specific - and that's intuitive because that's how OOP works - every
instance method call is 'context specific' with respec to the instance
you are calling. In the general traversal mechanism, both approaches
allow you to retrieve any sub-element in any namespace with equal
ease. For the convenience case, my model emphasises the ease of
traversal of a structure in the same, context-specific namespace,
yours emphasises the convenience of retrieving a sub-element in some
special-cased, distinguished namespace. 

>All the time. XSLT, SVG, and XML Schemas are two very common cases
where
>I'm constantly having children in a different namespace than the
parent.
>Well designed XSLT templates require this.

Sure, and if the namespaces are different, you use the general
traversal method which is identical to the one in the current
implementation. Neither the current convenience traversal method nor
the one I'm proposing is applicable in such a situation - you wouldn't
use it now, you wouldn't use it if it were changed.

[pvg] Concise, granted but easy and intuitive? I don't see the notion of
a

>I think so, given an understanding of the XML Namespace spec. YOu have
>to remember, we are intuitive as long as that intuitiveness is correct.
>We went through this a long time ago - if something is intuitive but
>WRONG, we won't put it in; we don't encourage bad use-patterns. That's
>why getText() no longer returns trimmed content. People expected it,
but
>they were WRONG, so we made sure to make them be right.

Ah but that's my point - _too much_ of the detail of the namespace
spec has bubbled up to the core model API, making it complex and
counter-intuitive, in an object system. The gist of my proposal is to
remove (partially, by taking out scoping/defaulting rules) or fully
(by relying on object-encapsulated, stable, unique element and
attribute types as described in Appendix A of the spec) the
extraneoius detail and move its complexities out of the core model and
into the implementation of the serialization facilities.

[pvg] prefixed or unprefixed names being directly represented in the
core
[pvg] API - certainly every method on Element that has anything to do
with
[pvg] names (besides getQualifiedName) deals with local names, always.
To

>Not true - it deals with local names AND a Namespace. There is never a
>use in the core of a local name along (even when it's only a local name
>passed in, a Namespace object is added and that's how the Element is
>dealt with). It's always a local name and Namespace.

Same in mine, the only difference being _what_ namespace is added in
the case of the convenience traversal method. In your's it's a
special-cased, distinguished namespace, in mine, it's the namespace of
instance you're calling. I've argued mine is more practical and more
OO-intuitive, but even if you disagree about the convenience method,
both are really a confusing mess. My full proposal (the long thing in
response to Ellioette this morning) wants to bind the notion of
namespace URI and local name in a single a specific object,
representing Element or Attribute type and make both the creation and
traversal APIs rely on that. This is both much safer and much simpler
then both the current state of affairs and my 'change getChild()/take
out the def. namespace' proposal. The only reason I started with the
getChild thing is because it came up and the removal of the default
namespace seemed like a sensible partial step in the right direction.
If you'd rather discuss the more general, prefix-less, element-type
based proposal I'd happily shut up about the getChild thing
immediately :) I think the encapsulated, stable element-type approach
is by far and away The Right Thing, it cuts away 90% of this debate
and I'm really much more interested in talking about it, hopefully
refining and agreeing on it and helping implement it. 


>Element parent = new Element("parent", myNamespace);
>parent.addChild(new Element("child"));

>is not the same as

>Element child = new Element("child");
>Element parent = new Element("parent", myNamespace);
>parent.addChild(child);

>Unless you change the whole API. That's a very confusing situation! I
>think if you add getChild(), you have to change addChild(), and on down
>the line... feels like a slippery slope.

Hang on, I don't want this! In my partial proposal both of these would
do exactly what they do now, I completely agree with the contract on
Element that makes namespaces immutable after instantiation. Once
you've set the namespace, no amount of moving and reparenting will
change it. The primary change in my partial proposal was to change the
behaviour of getChild(name) - that's about it. In my full proposal the
above will look like this (in full verbosity and assuming you know the
elements and namespaces you're interested in in advance (the 80% case,
its not true in generic metadata or transformation/set operation code
[schema/xslt/xpath] which one typically does not implement day to day):

[... somewhere in a globally accessible context ..]
NameSpace   MY_NS             = NameSpaceFactory.get("http://someURI");
ElementType MY_PAREN_ELEMTYPE = new ElementType("parent", ns);
ElementType MY_CHILD_ELEMTYPE = new ElementType("child", ns);

[... anywwhere else, with access to the above definitions ...]

Element parent = new Element(MY_PAREN_ELEMTYPE);
Element child  = new Element(MY_CHILD_ELEMTYPE);
parent.addContent(child);

done. look ma, no prefix! How about traversal? Same thing.

child = parent.getChild(MY_CHILD_ELEMTYPE);

transfer to a different doc?

child = parent.removeChild(MY_CHILD_ELEMTYPE);
newParent.addContent(child);

the nice thing about it is that the element and attribute types are
stable - they are independent of both documents in general and
serialized instances of the same document. To make it even more
consistent and performant, Element and Attribute types can also be
globally interned (requires a factory) since they are globally unique.
This simplifies and speeds up all comparison operations since they can
be done by identity comparison, e.g.

if (someElement.getType() == otherElement.gType())
{
   ...

It also encourages users to stay away from literal constants like
element.getChild("foobar"), a practice far worse and more fragile than
any variant of getChild behaviour we've discussed so far (yes, literal
string constants could be moved to external static class or interface
fields but that is only a syntactic change - they end up literally
embedded in every class file that uses them anyway)

The prefix mapping would be managed externally to the core model
classes. You might want to provide a facility to provide prefix
'hinting' for a particular context (most likely document) at namespace
creation time. Applying the mapping and producing well-formed,
namespace-spec compliant XML is then the job of the serializer. The
element and attribute type constructs are perfectly intuitive and
natural and if you're worried about spec compliance, the concept is
described in Appendix 1 of the namespace spec.


>Why? By definition, that really blows out a major component of the
>specification. I actually really like default namespaces, as they make
>life... well... easy...
[...]
>Again, though, prefixes are an intrinsic part of XML Namespaces. Or did
>I misunderstand you here?
[...]
>I think you are exaggerating here - what is so complex about it? In my
>book, I use namespaces in every example, and have not received a single
>question on them - and I get a ton of questions!

Prefix handling itself is massively complex. The way namespace is
represented in the current object model goes against the concept of
the spec in exchange for modelling a part of the spec that  has to
do with encoding, not concepts. A namespace is supposed to be unique,
JDOM models not the XML namespace concept but the XML namespace
encoding specification - probably worth modelling for serialization
but certainly not in the core (conceptual) api. Conceptually a
namespace is stable and globally unique and fully specified by a URI.
Conceptually, an expanded element or attribute type is stable and
globally unique and is fully specified by a namespace/local-name pair.
I think we should model these concepts in the core API directly and
explicitly, they make the whole thing more elegant, clean and
conceptually consistent than any other Java XML API out there - a true
_object_ model. We're getting bogged down in the whole getChild debate
which is really not all that important - I'd like to hear if anyone is
interested in implementing what I've just described (also outlined in
the last part in my response to Ellioette), in fact, I'm interested in
hearing any feedback, even if it is 'very nice, but not for JDOM' - it
helps JDOM because it defines more conceretely what JDOMs goals are
and it helps me because then I know to go implement this on top of
something else :)

-pvg







From zeclarks at sprynet.com  Thu Sep  7 19:57:03 2000
From: zeclarks at sprynet.com (Stacie Clark)
Date: Fri Aug  6 17:04:49 2004
Subject: [jdom-interest] xml namespaces
References: <39B82F9F.EB46CA1C@sprynet.com> <39B83D5B.ABF4196F@acm.org>
Message-ID: <39B8557F.712EDD9D@sprynet.com>

Actually now that I've gone back to it, I remember that most of the necessary changes
were in Namespace.java.  (I thought that with all the discussion about namespaces, that
the fixes might have been withheld)

The error that I am seeing comes from the function:
Verifier.checkNamespacePrefix(String prefix)
which is called from:
public static Namespace getNamespace(String prefix, String uri)
The error is produced because, logically, the xml prefix cannot be determined to be
valid without the URI.  The (prefix, URI) pair can be (xml,
"http://www.w3.org/XML/1998/namespace") or (xml, "")

When I looked at this last month, I fixed this problem by adding a guard clause to
public static Namespace getNamespace(String prefix, String uri) :

        if(isXmlNamespace(prefix, uri))
        {
            return (Namespace)namespaces.get(XML_NAMESPACE_URI);
        }

The clause uses this function in Namespace, which I also added:

   public static boolean isXmlNamespace(String prefix, String uri)
    {
       if(prefix.toLowerCase().equals(XML_PREFIX) && uri.equals(""))
       {
          return true;
       }
       if(uri.equals(XML_NAMESPACE_URI))
       {
          return true;
       }

       return false;
    }

The strigs are:
    public static final String XML_NAMESPACE_URI =
"http://www.w3.org/XML/1998/namespace";
    public static final String XML_PREFIX = "xml";

This fixed the problem tonight when I added it to Namespace.java

Jason Hunter wrote:

>  % grep xml:lang *.java
> Verifier.java:        // Allow xml:space and xml:lang as special cases
> Verifier.java:            name.equals("xml:lang")) {
>
> -jh-
>
> Stacie Clark wrote:
> >
> > Did the fix for xml:lang and xml:space not make it into CVS?  I just
> > tested on the latest code in CVS and I got an error.
> >
> > Stacie Clark
> >
> > _______________________________________________
> > To control your jdom-interest membership:
> > http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com


From jhunter at collab.net  Fri Sep  8 02:21:27 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:04:49 2004
Subject: [jdom-interest] xml namespaces
References: <39B82F9F.EB46CA1C@sprynet.com> <39B83D5B.ABF4196F@acm.org> <39B8557F.712EDD9D@sprynet.com>
Message-ID: <39B8AF97.20E7291C@collab.net>

> Actually now that I've gone back to it, I remember that most of 
> the necessary changes were in Namespace.java.  (I thought that 
> with all the discussion about namespaces, that
> the fixes might have been withheld)

Yeah, and I had them fixed but the fix was removed during the recent
Namespace shuffle.  I'm adding it back in, easy work thanks to the CVS
history.  :-)

Please test with the latest CVS and let me know if it still persists.

-jh-

From philion at acmerocket.com  Fri Sep  8 08:05:44 2000
From: philion at acmerocket.com (Paul Philion)
Date: Fri Aug  6 17:04:49 2004
Subject: [jdom-interest] Why not interfaces?
In-Reply-To: <39B808A6.F5F31159@collab.net>
Message-ID: <GEEIKGLIDNNEIBDLFCAMOELNDDAA.philion@acmerocket.com>

Note: This post contain my opinions about the role of interfaces in
Java software. If you are not interested, please delete.

Let's see if I have this correct:

Using interfaces in JDOM was scrapped because:

a) You can't dictate the behavior of equals().
b) It was more difficult to design and implement.

(If I've missed something, please let me know. I reviewed the
archives, and those are the issues that were discussed.)

An interesting comment from the archive:

    Before we would add something like that [...]
    we'd need a compelling and common use case
    for what someone would do with the
    functionality that can't be solved elegantly
    using the existing feature set.

Jason said that.

Jason, can you meet that criteria for the decision to remove
interfaces?

I don't think a) provides a "compelling" reason: The interface
document can clearly state that equals() should check for specific
instance equality. Sun takes this same route when documenting the
dependency between equals() and hashCode().

I don't think b) is a compelling reason either, as good design and
implementation are difficult, especially for simple, robust software.

Now, a clear and compelling use case for using interfaces:

  Parsing large, complex XML documents.

JDOM fails the same was DOM does: Before a document can be used, it
must be completely parsed. If you don't have enough memory, to bad. If
you're running on a small device, too bad. If you only need a few
important pieces in the document, too bad.

IF JDOM supported interfaces, I could implement a version of Document
that only parsed as much of the document as was necessary to provide
the requested data.

IF JDOM supported flexible factories, I could implement a light weight
caching parser that returned my on-demand Document.

Neither of these is possible today. Further, because of the concrete
nature of JDOM, it is less capable of handling unexpected needs in the
future.

Several people (in the archive) argued to use interface in "JDOM2". I
ask: "Why wait?"

- Paul Philion


> -----Original Message-----
> From: Jason Hunter [mailto:jhunter@collab.net]
> Sent: Thursday, September 07, 2000 5:29 PM
> To: Paul Philion
> Cc: jdom-interest@jdom.org
> Subject: Re: [jdom-interest] Why not interfaces?
>
>
> > I missed the original. Is there somewhere I can review it
> online? I
> > don't want to rehash a discussion that has already been had.
>
> The archives are online via the link from the web site.  Not easy to
> search except download a month and CTRL-F but it gets the job done.
>
> > 1) Making the Document thread-safe.
> >
> > - Looking over the latest code, Document is not
> thread-safe. I would
> > recommend a solution similar to the one offered by the Java 1.1
> > collections. Have a "standard" implementation that is *not*
> > thread-safe, and a method on the Document builder that is
> > "buildSynchronized", that wraps a synchronized wrapper around the
> > document.
>
> The FAQ addresses this.  We leave it to the programmer
> because we can't
> do much thread safety within the class, most has to be
> external, so we
> let all be external.
>
> > 2) Mandating how equals is handled.
> >
> > - One suggestion is to have a static utility method to
> compare to two
> > Documents. The "standard" implementation would use this. Novel
> > implementations of the Document (if it was an interface)
> could also
> > use it.
> >
> > I'm sure that you covered this, and other issues in your
> recent post.
> > I'd really like to read it before I step in it too deeply.
>
> I didn't write all *that much* about it because I know
> interfaces aren't
> something we're willing to switch (back) to.  We actuall
> started with
> interfaces in our private impls before going public, and
> believe me we
> were MUCH happier about the design with concrete classes.
>
> -jh-


From mengelhart at earthtrip.com  Fri Sep  8 10:43:52 2000
From: mengelhart at earthtrip.com (Michael Engelhart)
Date: Fri Aug  6 17:04:49 2004
Subject: [jdom-interest] question (help)
Message-ID: <02f6d4145170890SM1@mail.austin.rr.com>

Hi,

Yesterday I posted about a problem I'm having with the  
getAttributeValue(String name) method in the Element class which I didn't  
get a response to so I'm reposting since my question may not have been very  
clear.  Here goes:
If I have an attribute value which is an "escaped" string, the escape  
slash is removed upon retrieval.  Can anyone tell me if this is a bug or  
expected behavior?  If it's expected, please tell me why that happens so I  
can try and come up with a workaround.  The reason (in case anyone is  
questioning) that I have escaped strings is that i'm keeping a bunch of  
regular expressions stored in an xml document for retrieval and am using  
the ORO (now Apache) Perl utilities matching classes which require escaped  
strings in their patterns like this:
m/MAX\\s+([0-9]+)/s

which the getAttributeValue() mangles into:
m/MAX\s+([0-9]+)/s

not the single slash after "MAX" in the returned string.   I can't figure  
out why this would be the correct behavior but maybe it is.

Thanks for any insight

Mike

From jhunter at collab.net  Fri Sep  8 11:39:57 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:04:49 2004
Subject: [jdom-interest] Why not interfaces?
References: <GEEIKGLIDNNEIBDLFCAMOELNDDAA.philion@acmerocket.com>
Message-ID: <39B9327D.5BABFBE2@collab.net>

>   Parsing large, complex XML documents.
> 
> JDOM fails the same was DOM does: Before a document can be used, it
> must be completely parsed. If you don't have enough memory, to bad. If
> you're running on a small device, too bad. If you only need a few
> important pieces in the document, too bad.
> 
> IF JDOM supported interfaces, I could implement a version of Document
> that only parsed as much of the document as was necessary to provide
> the requested data.

You can do that today.  Write a subclass of Element!  The Element
implementation and design has specifically been created to support a
deferred parse design.

> IF JDOM supported flexible factories, I could implement a light weight
> caching parser that returned my on-demand Document.

Write a DeferredBuilder that builds a document containing
DeferredElement instances.  No generic factory model needed!  People
will interact with the document using the API of the base class Element,
but it'll behave according to the DeferredElement implementation.

-jh-

From brett.mclaughlin at lutris.com  Fri Sep  8 16:15:41 2000
From: brett.mclaughlin at lutris.com (Brett McLaughlin)
Date: Fri Aug  6 17:04:49 2004
Subject: [jdom-interest] question (help)
References: <02f6d4145170890SM1@mail.austin.rr.com>
Message-ID: <39B9731D.6E59ABFF@lutris.com>


Michael Engelhart wrote:
> 
> Hi,
> 
> Yesterday I posted about a problem I'm having with the
> getAttributeValue(String name) method in the Element class which I didn't
> get a response to so I'm reposting since my question may not have been very
> clear.  Here goes:
> If I have an attribute value which is an "escaped" string, the escape
> slash is removed upon retrieval.  Can anyone tell me if this is a bug or
> expected behavior?  If it's expected, please tell me why that happens so I
> can try and come up with a workaround.  The reason (in case anyone is
> questioning) that I have escaped strings is that i'm keeping a bunch of
> regular expressions stored in an xml document for retrieval and am using
> the ORO (now Apache) Perl utilities matching classes which require escaped
> strings in their patterns like this:
> m/MAX\\s+([0-9]+)/s
> 
> which the getAttributeValue() mangles into:
> m/MAX\s+([0-9]+)/s
> 
> not the single slash after "MAX" in the returned string.   I can't figure
> out why this would be the correct behavior but maybe it is.

Hey, Mike-

  For sure, it's a bug. I've got it pn my list to look at and just
haven't gotten a chance yet ... I'll try to fix that this weekend. Sorry
for the delay in a response ;-)

-Brett

> 
> Thanks for any insight
> 
> Mike
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org

From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:49 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:49 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From veerpal at hotbot.com  Fri Sep  8 12:12:39 2000
From: veerpal at hotbot.com (veerpal singh)
Date: Fri Aug  6 17:04:49 2004
Subject: [jdom-interest] ID and IDREF
Message-ID: <MFFEPMMIAENICAAA@hotbot.com>

 Hi 

Sorry for the delay in answer. I think I need exactly what my friend has said. I f i encounter IDREF I should be able to get XML element which refers to the that IDREF and parameter will be value of idref attribute. By that way I will able to cross reference XML objects
Thanks
VS

--

On Tue, 05 Sep 2000 18:07:25   Brett McLaughlin wrote:
>
>
>veerpal singh wrote:
>> 
>> Hi All
>> 
>> I was just looking around on net for ID and IDREF processing. Is it possible thru jdom that when idref is encountered, element having iD can be retrieved. Or has to be done by higher level appl.
>
>What do you need to be able to do, and what would you expect the API to
>look like? Finally, what's your use-case for these changes.
>
>Let us know, and I'll look at what it would take to do.
>
>-Brett
>
>> 
>> Thanks
>> VS
>> 
>> HotBot - Search smarter.
>> http://www.hotbot.com
>> _______________________________________________
>> To control your jdom-interest membership:
>> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
>
>-- 
>Brett McLaughlin, Enhydra Strategist
>Lutris Technologies, Inc. 
>1200 Pacific Avenue, Suite 300 
>Santa Cruz, CA 95060 USA 
>http://www.lutris.com
>http://www.enhydra.org
>


HotBot - Search smarter.
http://www.hotbot.com

From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:49 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:49 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From veerpal at hotbot.com  Fri Sep  8 12:12:39 2000
From: veerpal at hotbot.com (veerpal singh)
Date: Fri Aug  6 17:04:49 2004
Subject: [jdom-interest] ID and IDREF
Message-ID: <MFFEPMMIAENICAAA@hotbot.com>

 Hi 

Sorry for the delay in answer. I think I need exactly what my friend has said. I f i encounter IDREF I should be able to get XML element which refers to the that IDREF and parameter will be value of idref attribute. By that way I will able to cross reference XML objects
Thanks
VS

--

On Tue, 05 Sep 2000 18:07:25   Brett McLaughlin wrote:
>
>
>veerpal singh wrote:
>> 
>> Hi All
>> 
>> I was just looking around on net for ID and IDREF processing. Is it possible thru jdom that when idref is encountered, element having iD can be retrieved. Or has to be done by higher level appl.
>
>What do you need to be able to do, and what would you expect the API to
>look like? Finally, what's your use-case for these changes.
>
>Let us know, and I'll look at what it would take to do.
>
>-Brett
>
>> 
>> Thanks
>> VS
>> 
>> HotBot - Search smarter.
>> http://www.hotbot.com
>> _______________________________________________
>> To control your jdom-interest membership:
>> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
>
>-- 
>Brett McLaughlin, Enhydra Strategist
>Lutris Technologies, Inc. 
>1200 Pacific Avenue, Suite 300 
>Santa Cruz, CA 95060 USA 
>http://www.lutris.com
>http://www.enhydra.org
>


HotBot - Search smarter.
http://www.hotbot.com

From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:49 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:49 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From veerpal at hotbot.com  Fri Sep  8 12:12:39 2000
From: veerpal at hotbot.com (veerpal singh)
Date: Fri Aug  6 17:04:49 2004
Subject: [jdom-interest] ID and IDREF
Message-ID: <MFFEPMMIAENICAAA@hotbot.com>

 Hi 

Sorry for the delay in answer. I think I need exactly what my friend has said. I f i encounter IDREF I should be able to get XML element which refers to the that IDREF and parameter will be value of idref attribute. By that way I will able to cross reference XML objects
Thanks
VS

--

On Tue, 05 Sep 2000 18:07:25   Brett McLaughlin wrote:
>
>
>veerpal singh wrote:
>> 
>> Hi All
>> 
>> I was just looking around on net for ID and IDREF processing. Is it possible thru jdom that when idref is encountered, element having iD can be retrieved. Or has to be done by higher level appl.
>
>What do you need to be able to do, and what would you expect the API to
>look like? Finally, what's your use-case for these changes.
>
>Let us know, and I'll look at what it would take to do.
>
>-Brett
>
>> 
>> Thanks
>> VS
>> 
>> HotBot - Search smarter.
>> http://www.hotbot.com
>> _______________________________________________
>> To control your jdom-interest membership:
>> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
>
>-- 
>Brett McLaughlin, Enhydra Strategist
>Lutris Technologies, Inc. 
>1200 Pacific Avenue, Suite 300 
>Santa Cruz, CA 95060 USA 
>http://www.lutris.com
>http://www.enhydra.org
>


HotBot - Search smarter.
http://www.hotbot.com

From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:49 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:49 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From veerpal at hotbot.com  Fri Sep  8 12:12:39 2000
From: veerpal at hotbot.com (veerpal singh)
Date: Fri Aug  6 17:04:49 2004
Subject: [jdom-interest] ID and IDREF
Message-ID: <MFFEPMMIAENICAAA@hotbot.com>

 Hi 

Sorry for the delay in answer. I think I need exactly what my friend has said. I f i encounter IDREF I should be able to get XML element which refers to the that IDREF and parameter will be value of idref attribute. By that way I will able to cross reference XML objects
Thanks
VS

--

On Tue, 05 Sep 2000 18:07:25   Brett McLaughlin wrote:
>
>
>veerpal singh wrote:
>> 
>> Hi All
>> 
>> I was just looking around on net for ID and IDREF processing. Is it possible thru jdom that when idref is encountered, element having iD can be retrieved. Or has to be done by higher level appl.
>
>What do you need to be able to do, and what would you expect the API to
>look like? Finally, what's your use-case for these changes.
>
>Let us know, and I'll look at what it would take to do.
>
>-Brett
>
>> 
>> Thanks
>> VS
>> 
>> HotBot - Search smarter.
>> http://www.hotbot.com
>> _______________________________________________
>> To control your jdom-interest membership:
>> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
>
>-- 
>Brett McLaughlin, Enhydra Strategist
>Lutris Technologies, Inc. 
>1200 Pacific Avenue, Suite 300 
>Santa Cruz, CA 95060 USA 
>http://www.lutris.com
>http://www.enhydra.org
>


HotBot - Search smarter.
http://www.hotbot.com

From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:49 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:49 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From veerpal at hotbot.com  Fri Sep  8 12:12:39 2000
From: veerpal at hotbot.com (veerpal singh)
Date: Fri Aug  6 17:04:49 2004
Subject: [jdom-interest] ID and IDREF
Message-ID: <MFFEPMMIAENICAAA@hotbot.com>

 Hi 

Sorry for the delay in answer. I think I need exactly what my friend has said. I f i encounter IDREF I should be able to get XML element which refers to the that IDREF and parameter will be value of idref attribute. By that way I will able to cross reference XML objects
Thanks
VS

--

On Tue, 05 Sep 2000 18:07:25   Brett McLaughlin wrote:
>
>
>veerpal singh wrote:
>> 
>> Hi All
>> 
>> I was just looking around on net for ID and IDREF processing. Is it possible thru jdom that when idref is encountered, element having iD can be retrieved. Or has to be done by higher level appl.
>
>What do you need to be able to do, and what would you expect the API to
>look like? Finally, what's your use-case for these changes.
>
>Let us know, and I'll look at what it would take to do.
>
>-Brett
>
>> 
>> Thanks
>> VS
>> 
>> HotBot - Search smarter.
>> http://www.hotbot.com
>> _______________________________________________
>> To control your jdom-interest membership:
>> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
>
>-- 
>Brett McLaughlin, Enhydra Strategist
>Lutris Technologies, Inc. 
>1200 Pacific Avenue, Suite 300 
>Santa Cruz, CA 95060 USA 
>http://www.lutris.com
>http://www.enhydra.org
>


HotBot - Search smarter.
http://www.hotbot.com

From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:49 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:49 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From veerpal at hotbot.com  Fri Sep  8 12:12:39 2000
From: veerpal at hotbot.com (veerpal singh)
Date: Fri Aug  6 17:04:49 2004
Subject: [jdom-interest] ID and IDREF
Message-ID: <MFFEPMMIAENICAAA@hotbot.com>

 Hi 

Sorry for the delay in answer. I think I need exactly what my friend has said. I f i encounter IDREF I should be able to get XML element which refers to the that IDREF and parameter will be value of idref attribute. By that way I will able to cross reference XML objects
Thanks
VS

--

On Tue, 05 Sep 2000 18:07:25   Brett McLaughlin wrote:
>
>
>veerpal singh wrote:
>> 
>> Hi All
>> 
>> I was just looking around on net for ID and IDREF processing. Is it possible thru jdom that when idref is encountered, element having iD can be retrieved. Or has to be done by higher level appl.
>
>What do you need to be able to do, and what would you expect the API to
>look like? Finally, what's your use-case for these changes.
>
>Let us know, and I'll look at what it would take to do.
>
>-Brett
>
>> 
>> Thanks
>> VS
>> 
>> HotBot - Search smarter.
>> http://www.hotbot.com
>> _______________________________________________
>> To control your jdom-interest membership:
>> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
>
>-- 
>Brett McLaughlin, Enhydra Strategist
>Lutris Technologies, Inc. 
>1200 Pacific Avenue, Suite 300 
>Santa Cruz, CA 95060 USA 
>http://www.lutris.com
>http://www.enhydra.org
>


HotBot - Search smarter.
http://www.hotbot.com

From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:49 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:49 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From veerpal at hotbot.com  Fri Sep  8 12:12:39 2000
From: veerpal at hotbot.com (veerpal singh)
Date: Fri Aug  6 17:04:49 2004
Subject: [jdom-interest] ID and IDREF
Message-ID: <MFFEPMMIAENICAAA@hotbot.com>

 Hi 

Sorry for the delay in answer. I think I need exactly what my friend has said. I f i encounter IDREF I should be able to get XML element which refers to the that IDREF and parameter will be value of idref attribute. By that way I will able to cross reference XML objects
Thanks
VS

--

On Tue, 05 Sep 2000 18:07:25   Brett McLaughlin wrote:
>
>
>veerpal singh wrote:
>> 
>> Hi All
>> 
>> I was just looking around on net for ID and IDREF processing. Is it possible thru jdom that when idref is encountered, element having iD can be retrieved. Or has to be done by higher level appl.
>
>What do you need to be able to do, and what would you expect the API to
>look like? Finally, what's your use-case for these changes.
>
>Let us know, and I'll look at what it would take to do.
>
>-Brett
>
>> 
>> Thanks
>> VS
>> 
>> HotBot - Search smarter.
>> http://www.hotbot.com
>> _______________________________________________
>> To control your jdom-interest membership:
>> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
>
>-- 
>Brett McLaughlin, Enhydra Strategist
>Lutris Technologies, Inc. 
>1200 Pacific Avenue, Suite 300 
>Santa Cruz, CA 95060 USA 
>http://www.lutris.com
>http://www.enhydra.org
>


HotBot - Search smarter.
http://www.hotbot.com

From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:49 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:49 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From veerpal at hotbot.com  Fri Sep  8 12:12:39 2000
From: veerpal at hotbot.com (veerpal singh)
Date: Fri Aug  6 17:04:49 2004
Subject: [jdom-interest] ID and IDREF
Message-ID: <MFFEPMMIAENICAAA@hotbot.com>

 Hi 

Sorry for the delay in answer. I think I need exactly what my friend has said. I f i encounter IDREF I should be able to get XML element which refers to the that IDREF and parameter will be value of idref attribute. By that way I will able to cross reference XML objects
Thanks
VS

--

On Tue, 05 Sep 2000 18:07:25   Brett McLaughlin wrote:
>
>
>veerpal singh wrote:
>> 
>> Hi All
>> 
>> I was just looking around on net for ID and IDREF processing. Is it possible thru jdom that when idref is encountered, element having iD can be retrieved. Or has to be done by higher level appl.
>
>What do you need to be able to do, and what would you expect the API to
>look like? Finally, what's your use-case for these changes.
>
>Let us know, and I'll look at what it would take to do.
>
>-Brett
>
>> 
>> Thanks
>> VS
>> 
>> HotBot - Search smarter.
>> http://www.hotbot.com
>> _______________________________________________
>> To control your jdom-interest membership:
>> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
>
>-- 
>Brett McLaughlin, Enhydra Strategist
>Lutris Technologies, Inc. 
>1200 Pacific Avenue, Suite 300 
>Santa Cruz, CA 95060 USA 
>http://www.lutris.com
>http://www.enhydra.org
>


HotBot - Search smarter.
http://www.hotbot.com

From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:49 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:49 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From veerpal at hotbot.com  Fri Sep  8 12:12:39 2000
From: veerpal at hotbot.com (veerpal singh)
Date: Fri Aug  6 17:04:49 2004
Subject: [jdom-interest] ID and IDREF
Message-ID: <MFFEPMMIAENICAAA@hotbot.com>

 Hi 

Sorry for the delay in answer. I think I need exactly what my friend has said. I f i encounter IDREF I should be able to get XML element which refers to the that IDREF and parameter will be value of idref attribute. By that way I will able to cross reference XML objects
Thanks
VS

--

On Tue, 05 Sep 2000 18:07:25   Brett McLaughlin wrote:
>
>
>veerpal singh wrote:
>> 
>> Hi All
>> 
>> I was just looking around on net for ID and IDREF processing. Is it possible thru jdom that when idref is encountered, element having iD can be retrieved. Or has to be done by higher level appl.
>
>What do you need to be able to do, and what would you expect the API to
>look like? Finally, what's your use-case for these changes.
>
>Let us know, and I'll look at what it would take to do.
>
>-Brett
>
>> 
>> Thanks
>> VS
>> 
>> HotBot - Search smarter.
>> http://www.hotbot.com
>> _______________________________________________
>> To control your jdom-interest membership:
>> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
>
>-- 
>Brett McLaughlin, Enhydra Strategist
>Lutris Technologies, Inc. 
>1200 Pacific Avenue, Suite 300 
>Santa Cruz, CA 95060 USA 
>http://www.lutris.com
>http://www.enhydra.org
>


HotBot - Search smarter.
http://www.hotbot.com

From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:49 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:49 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From veerpal at hotbot.com  Fri Sep  8 12:12:39 2000
From: veerpal at hotbot.com (veerpal singh)
Date: Fri Aug  6 17:04:49 2004
Subject: [jdom-interest] ID and IDREF
Message-ID: <MFFEPMMIAENICAAA@hotbot.com>

 Hi 

Sorry for the delay in answer. I think I need exactly what my friend has said. I f i encounter IDREF I should be able to get XML element which refers to the that IDREF and parameter will be value of idref attribute. By that way I will able to cross reference XML objects
Thanks
VS

--

On Tue, 05 Sep 2000 18:07:25   Brett McLaughlin wrote:
>
>
>veerpal singh wrote:
>> 
>> Hi All
>> 
>> I was just looking around on net for ID and IDREF processing. Is it possible thru jdom that when idref is encountered, element having iD can be retrieved. Or has to be done by higher level appl.
>
>What do you need to be able to do, and what would you expect the API to
>look like? Finally, what's your use-case for these changes.
>
>Let us know, and I'll look at what it would take to do.
>
>-Brett
>
>> 
>> Thanks
>> VS
>> 
>> HotBot - Search smarter.
>> http://www.hotbot.com
>> _______________________________________________
>> To control your jdom-interest membership:
>> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
>
>-- 
>Brett McLaughlin, Enhydra Strategist
>Lutris Technologies, Inc. 
>1200 Pacific Avenue, Suite 300 
>Santa Cruz, CA 95060 USA 
>http://www.lutris.com
>http://www.enhydra.org
>


HotBot - Search smarter.
http://www.hotbot.com

From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:50 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:50 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From veerpal at hotbot.com  Fri Sep  8 12:12:39 2000
From: veerpal at hotbot.com (veerpal singh)
Date: Fri Aug  6 17:04:50 2004
Subject: [jdom-interest] ID and IDREF
Message-ID: <MFFEPMMIAENICAAA@hotbot.com>

 Hi 

Sorry for the delay in answer. I think I need exactly what my friend has said. I f i encounter IDREF I should be able to get XML element which refers to the that IDREF and parameter will be value of idref attribute. By that way I will able to cross reference XML objects
Thanks
VS

--

On Tue, 05 Sep 2000 18:07:25   Brett McLaughlin wrote:
>
>
>veerpal singh wrote:
>> 
>> Hi All
>> 
>> I was just looking around on net for ID and IDREF processing. Is it possible thru jdom that when idref is encountered, element having iD can be retrieved. Or has to be done by higher level appl.
>
>What do you need to be able to do, and what would you expect the API to
>look like? Finally, what's your use-case for these changes.
>
>Let us know, and I'll look at what it would take to do.
>
>-Brett
>
>> 
>> Thanks
>> VS
>> 
>> HotBot - Search smarter.
>> http://www.hotbot.com
>> _______________________________________________
>> To control your jdom-interest membership:
>> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
>
>-- 
>Brett McLaughlin, Enhydra Strategist
>Lutris Technologies, Inc. 
>1200 Pacific Avenue, Suite 300 
>Santa Cruz, CA 95060 USA 
>http://www.lutris.com
>http://www.enhydra.org
>


HotBot - Search smarter.
http://www.hotbot.com

From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:50 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:50 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From veerpal at hotbot.com  Fri Sep  8 12:12:39 2000
From: veerpal at hotbot.com (veerpal singh)
Date: Fri Aug  6 17:04:50 2004
Subject: [jdom-interest] ID and IDREF
Message-ID: <MFFEPMMIAENICAAA@hotbot.com>

 Hi 

Sorry for the delay in answer. I think I need exactly what my friend has said. I f i encounter IDREF I should be able to get XML element which refers to the that IDREF and parameter will be value of idref attribute. By that way I will able to cross reference XML objects
Thanks
VS

--

On Tue, 05 Sep 2000 18:07:25   Brett McLaughlin wrote:
>
>
>veerpal singh wrote:
>> 
>> Hi All
>> 
>> I was just looking around on net for ID and IDREF processing. Is it possible thru jdom that when idref is encountered, element having iD can be retrieved. Or has to be done by higher level appl.
>
>What do you need to be able to do, and what would you expect the API to
>look like? Finally, what's your use-case for these changes.
>
>Let us know, and I'll look at what it would take to do.
>
>-Brett
>
>> 
>> Thanks
>> VS
>> 
>> HotBot - Search smarter.
>> http://www.hotbot.com
>> _______________________________________________
>> To control your jdom-interest membership:
>> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
>
>-- 
>Brett McLaughlin, Enhydra Strategist
>Lutris Technologies, Inc. 
>1200 Pacific Avenue, Suite 300 
>Santa Cruz, CA 95060 USA 
>http://www.lutris.com
>http://www.enhydra.org
>


HotBot - Search smarter.
http://www.hotbot.com

From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:50 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:50 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From veerpal at hotbot.com  Fri Sep  8 12:12:39 2000
From: veerpal at hotbot.com (veerpal singh)
Date: Fri Aug  6 17:04:50 2004
Subject: [jdom-interest] ID and IDREF
Message-ID: <MFFEPMMIAENICAAA@hotbot.com>

 Hi 

Sorry for the delay in answer. I think I need exactly what my friend has said. I f i encounter IDREF I should be able to get XML element which refers to the that IDREF and parameter will be value of idref attribute. By that way I will able to cross reference XML objects
Thanks
VS

--

On Tue, 05 Sep 2000 18:07:25   Brett McLaughlin wrote:
>
>
>veerpal singh wrote:
>> 
>> Hi All
>> 
>> I was just looking around on net for ID and IDREF processing. Is it possible thru jdom that when idref is encountered, element having iD can be retrieved. Or has to be done by higher level appl.
>
>What do you need to be able to do, and what would you expect the API to
>look like? Finally, what's your use-case for these changes.
>
>Let us know, and I'll look at what it would take to do.
>
>-Brett
>
>> 
>> Thanks
>> VS
>> 
>> HotBot - Search smarter.
>> http://www.hotbot.com
>> _______________________________________________
>> To control your jdom-interest membership:
>> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
>
>-- 
>Brett McLaughlin, Enhydra Strategist
>Lutris Technologies, Inc. 
>1200 Pacific Avenue, Suite 300 
>Santa Cruz, CA 95060 USA 
>http://www.lutris.com
>http://www.enhydra.org
>


HotBot - Search smarter.
http://www.hotbot.com

From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:50 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:50 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From veerpal at hotbot.com  Fri Sep  8 12:12:39 2000
From: veerpal at hotbot.com (veerpal singh)
Date: Fri Aug  6 17:04:50 2004
Subject: [jdom-interest] ID and IDREF
Message-ID: <MFFEPMMIAENICAAA@hotbot.com>

 Hi 

Sorry for the delay in answer. I think I need exactly what my friend has said. I f i encounter IDREF I should be able to get XML element which refers to the that IDREF and parameter will be value of idref attribute. By that way I will able to cross reference XML objects
Thanks
VS

--

On Tue, 05 Sep 2000 18:07:25   Brett McLaughlin wrote:
>
>
>veerpal singh wrote:
>> 
>> Hi All
>> 
>> I was just looking around on net for ID and IDREF processing. Is it possible thru jdom that when idref is encountered, element having iD can be retrieved. Or has to be done by higher level appl.
>
>What do you need to be able to do, and what would you expect the API to
>look like? Finally, what's your use-case for these changes.
>
>Let us know, and I'll look at what it would take to do.
>
>-Brett
>
>> 
>> Thanks
>> VS
>> 
>> HotBot - Search smarter.
>> http://www.hotbot.com
>> _______________________________________________
>> To control your jdom-interest membership:
>> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
>
>-- 
>Brett McLaughlin, Enhydra Strategist
>Lutris Technologies, Inc. 
>1200 Pacific Avenue, Suite 300 
>Santa Cruz, CA 95060 USA 
>http://www.lutris.com
>http://www.enhydra.org
>


HotBot - Search smarter.
http://www.hotbot.com

From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:50 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:50 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From veerpal at hotbot.com  Fri Sep  8 12:12:39 2000
From: veerpal at hotbot.com (veerpal singh)
Date: Fri Aug  6 17:04:50 2004
Subject: [jdom-interest] ID and IDREF
Message-ID: <MFFEPMMIAENICAAA@hotbot.com>

 Hi 

Sorry for the delay in answer. I think I need exactly what my friend has said. I f i encounter IDREF I should be able to get XML element which refers to the that IDREF and parameter will be value of idref attribute. By that way I will able to cross reference XML objects
Thanks
VS

--

On Tue, 05 Sep 2000 18:07:25   Brett McLaughlin wrote:
>
>
>veerpal singh wrote:
>> 
>> Hi All
>> 
>> I was just looking around on net for ID and IDREF processing. Is it possible thru jdom that when idref is encountered, element having iD can be retrieved. Or has to be done by higher level appl.
>
>What do you need to be able to do, and what would you expect the API to
>look like? Finally, what's your use-case for these changes.
>
>Let us know, and I'll look at what it would take to do.
>
>-Brett
>
>> 
>> Thanks
>> VS
>> 
>> HotBot - Search smarter.
>> http://www.hotbot.com
>> _______________________________________________
>> To control your jdom-interest membership:
>> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
>
>-- 
>Brett McLaughlin, Enhydra Strategist
>Lutris Technologies, Inc. 
>1200 Pacific Avenue, Suite 300 
>Santa Cruz, CA 95060 USA 
>http://www.lutris.com
>http://www.enhydra.org
>


HotBot - Search smarter.
http://www.hotbot.com

From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:50 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:50 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From veerpal at hotbot.com  Fri Sep  8 12:12:39 2000
From: veerpal at hotbot.com (veerpal singh)
Date: Fri Aug  6 17:04:50 2004
Subject: [jdom-interest] ID and IDREF
Message-ID: <MFFEPMMIAENICAAA@hotbot.com>

 Hi 

Sorry for the delay in answer. I think I need exactly what my friend has said. I f i encounter IDREF I should be able to get XML element which refers to the that IDREF and parameter will be value of idref attribute. By that way I will able to cross reference XML objects
Thanks
VS

--

On Tue, 05 Sep 2000 18:07:25   Brett McLaughlin wrote:
>
>
>veerpal singh wrote:
>> 
>> Hi All
>> 
>> I was just looking around on net for ID and IDREF processing. Is it possible thru jdom that when idref is encountered, element having iD can be retrieved. Or has to be done by higher level appl.
>
>What do you need to be able to do, and what would you expect the API to
>look like? Finally, what's your use-case for these changes.
>
>Let us know, and I'll look at what it would take to do.
>
>-Brett
>
>> 
>> Thanks
>> VS
>> 
>> HotBot - Search smarter.
>> http://www.hotbot.com
>> _______________________________________________
>> To control your jdom-interest membership:
>> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
>
>-- 
>Brett McLaughlin, Enhydra Strategist
>Lutris Technologies, Inc. 
>1200 Pacific Avenue, Suite 300 
>Santa Cruz, CA 95060 USA 
>http://www.lutris.com
>http://www.enhydra.org
>


HotBot - Search smarter.
http://www.hotbot.com

From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:50 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:50 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From veerpal at hotbot.com  Fri Sep  8 12:12:39 2000
From: veerpal at hotbot.com (veerpal singh)
Date: Fri Aug  6 17:04:50 2004
Subject: [jdom-interest] ID and IDREF
Message-ID: <MFFEPMMIAENICAAA@hotbot.com>

 Hi 

Sorry for the delay in answer. I think I need exactly what my friend has said. I f i encounter IDREF I should be able to get XML element which refers to the that IDREF and parameter will be value of idref attribute. By that way I will able to cross reference XML objects
Thanks
VS

--

On Tue, 05 Sep 2000 18:07:25   Brett McLaughlin wrote:
>
>
>veerpal singh wrote:
>> 
>> Hi All
>> 
>> I was just looking around on net for ID and IDREF processing. Is it possible thru jdom that when idref is encountered, element having iD can be retrieved. Or has to be done by higher level appl.
>
>What do you need to be able to do, and what would you expect the API to
>look like? Finally, what's your use-case for these changes.
>
>Let us know, and I'll look at what it would take to do.
>
>-Brett
>
>> 
>> Thanks
>> VS
>> 
>> HotBot - Search smarter.
>> http://www.hotbot.com
>> _______________________________________________
>> To control your jdom-interest membership:
>> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
>
>-- 
>Brett McLaughlin, Enhydra Strategist
>Lutris Technologies, Inc. 
>1200 Pacific Avenue, Suite 300 
>Santa Cruz, CA 95060 USA 
>http://www.lutris.com
>http://www.enhydra.org
>


HotBot - Search smarter.
http://www.hotbot.com

From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:50 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:50 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From veerpal at hotbot.com  Fri Sep  8 12:12:39 2000
From: veerpal at hotbot.com (veerpal singh)
Date: Fri Aug  6 17:04:50 2004
Subject: [jdom-interest] ID and IDREF
Message-ID: <MFFEPMMIAENICAAA@hotbot.com>

 Hi 

Sorry for the delay in answer. I think I need exactly what my friend has said. I f i encounter IDREF I should be able to get XML element which refers to the that IDREF and parameter will be value of idref attribute. By that way I will able to cross reference XML objects
Thanks
VS

--

On Tue, 05 Sep 2000 18:07:25   Brett McLaughlin wrote:
>
>
>veerpal singh wrote:
>> 
>> Hi All
>> 
>> I was just looking around on net for ID and IDREF processing. Is it possible thru jdom that when idref is encountered, element having iD can be retrieved. Or has to be done by higher level appl.
>
>What do you need to be able to do, and what would you expect the API to
>look like? Finally, what's your use-case for these changes.
>
>Let us know, and I'll look at what it would take to do.
>
>-Brett
>
>> 
>> Thanks
>> VS
>> 
>> HotBot - Search smarter.
>> http://www.hotbot.com
>> _______________________________________________
>> To control your jdom-interest membership:
>> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
>
>-- 
>Brett McLaughlin, Enhydra Strategist
>Lutris Technologies, Inc. 
>1200 Pacific Avenue, Suite 300 
>Santa Cruz, CA 95060 USA 
>http://www.lutris.com
>http://www.enhydra.org
>


HotBot - Search smarter.
http://www.hotbot.com

From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:50 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:50 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From veerpal at hotbot.com  Fri Sep  8 12:12:39 2000
From: veerpal at hotbot.com (veerpal singh)
Date: Fri Aug  6 17:04:50 2004
Subject: [jdom-interest] ID and IDREF
Message-ID: <MFFEPMMIAENICAAA@hotbot.com>

 Hi 

Sorry for the delay in answer. I think I need exactly what my friend has said. I f i encounter IDREF I should be able to get XML element which refers to the that IDREF and parameter will be value of idref attribute. By that way I will able to cross reference XML objects
Thanks
VS

--

On Tue, 05 Sep 2000 18:07:25   Brett McLaughlin wrote:
>
>
>veerpal singh wrote:
>> 
>> Hi All
>> 
>> I was just looking around on net for ID and IDREF processing. Is it possible thru jdom that when idref is encountered, element having iD can be retrieved. Or has to be done by higher level appl.
>
>What do you need to be able to do, and what would you expect the API to
>look like? Finally, what's your use-case for these changes.
>
>Let us know, and I'll look at what it would take to do.
>
>-Brett
>
>> 
>> Thanks
>> VS
>> 
>> HotBot - Search smarter.
>> http://www.hotbot.com
>> _______________________________________________
>> To control your jdom-interest membership:
>> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
>
>-- 
>Brett McLaughlin, Enhydra Strategist
>Lutris Technologies, Inc. 
>1200 Pacific Avenue, Suite 300 
>Santa Cruz, CA 95060 USA 
>http://www.lutris.com
>http://www.enhydra.org
>


HotBot - Search smarter.
http://www.hotbot.com

From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:50 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:50 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From veerpal at hotbot.com  Fri Sep  8 12:12:39 2000
From: veerpal at hotbot.com (veerpal singh)
Date: Fri Aug  6 17:04:50 2004
Subject: [jdom-interest] ID and IDREF
Message-ID: <MFFEPMMIAENICAAA@hotbot.com>

 Hi 

Sorry for the delay in answer. I think I need exactly what my friend has said. I f i encounter IDREF I should be able to get XML element which refers to the that IDREF and parameter will be value of idref attribute. By that way I will able to cross reference XML objects
Thanks
VS

--

On Tue, 05 Sep 2000 18:07:25   Brett McLaughlin wrote:
>
>
>veerpal singh wrote:
>> 
>> Hi All
>> 
>> I was just looking around on net for ID and IDREF processing. Is it possible thru jdom that when idref is encountered, element having iD can be retrieved. Or has to be done by higher level appl.
>
>What do you need to be able to do, and what would you expect the API to
>look like? Finally, what's your use-case for these changes.
>
>Let us know, and I'll look at what it would take to do.
>
>-Brett
>
>> 
>> Thanks
>> VS
>> 
>> HotBot - Search smarter.
>> http://www.hotbot.com
>> _______________________________________________
>> To control your jdom-interest membership:
>> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
>
>-- 
>Brett McLaughlin, Enhydra Strategist
>Lutris Technologies, Inc. 
>1200 Pacific Avenue, Suite 300 
>Santa Cruz, CA 95060 USA 
>http://www.lutris.com
>http://www.enhydra.org
>


HotBot - Search smarter.
http://www.hotbot.com

From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:50 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:50 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From veerpal at hotbot.com  Fri Sep  8 12:12:39 2000
From: veerpal at hotbot.com (veerpal singh)
Date: Fri Aug  6 17:04:50 2004
Subject: [jdom-interest] ID and IDREF
Message-ID: <MFFEPMMIAENICAAA@hotbot.com>

 Hi 

Sorry for the delay in answer. I think I need exactly what my friend has said. I f i encounter IDREF I should be able to get XML element which refers to the that IDREF and parameter will be value of idref attribute. By that way I will able to cross reference XML objects
Thanks
VS

--

On Tue, 05 Sep 2000 18:07:25   Brett McLaughlin wrote:
>
>
>veerpal singh wrote:
>> 
>> Hi All
>> 
>> I was just looking around on net for ID and IDREF processing. Is it possible thru jdom that when idref is encountered, element having iD can be retrieved. Or has to be done by higher level appl.
>
>What do you need to be able to do, and what would you expect the API to
>look like? Finally, what's your use-case for these changes.
>
>Let us know, and I'll look at what it would take to do.
>
>-Brett
>
>> 
>> Thanks
>> VS
>> 
>> HotBot - Search smarter.
>> http://www.hotbot.com
>> _______________________________________________
>> To control your jdom-interest membership:
>> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
>
>-- 
>Brett McLaughlin, Enhydra Strategist
>Lutris Technologies, Inc. 
>1200 Pacific Avenue, Suite 300 
>Santa Cruz, CA 95060 USA 
>http://www.lutris.com
>http://www.enhydra.org
>


HotBot - Search smarter.
http://www.hotbot.com

From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:50 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:50 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From veerpal at hotbot.com  Fri Sep  8 12:12:39 2000
From: veerpal at hotbot.com (veerpal singh)
Date: Fri Aug  6 17:04:50 2004
Subject: [jdom-interest] ID and IDREF
Message-ID: <MFFEPMMIAENICAAA@hotbot.com>

 Hi 

Sorry for the delay in answer. I think I need exactly what my friend has said. I f i encounter IDREF I should be able to get XML element which refers to the that IDREF and parameter will be value of idref attribute. By that way I will able to cross reference XML objects
Thanks
VS

--

On Tue, 05 Sep 2000 18:07:25   Brett McLaughlin wrote:
>
>
>veerpal singh wrote:
>> 
>> Hi All
>> 
>> I was just looking around on net for ID and IDREF processing. Is it possible thru jdom that when idref is encountered, element having iD can be retrieved. Or has to be done by higher level appl.
>
>What do you need to be able to do, and what would you expect the API to
>look like? Finally, what's your use-case for these changes.
>
>Let us know, and I'll look at what it would take to do.
>
>-Brett
>
>> 
>> Thanks
>> VS
>> 
>> HotBot - Search smarter.
>> http://www.hotbot.com
>> _______________________________________________
>> To control your jdom-interest membership:
>> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
>
>-- 
>Brett McLaughlin, Enhydra Strategist
>Lutris Technologies, Inc. 
>1200 Pacific Avenue, Suite 300 
>Santa Cruz, CA 95060 USA 
>http://www.lutris.com
>http://www.enhydra.org
>


HotBot - Search smarter.
http://www.hotbot.com

From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:50 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:50 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From veerpal at hotbot.com  Fri Sep  8 12:12:39 2000
From: veerpal at hotbot.com (veerpal singh)
Date: Fri Aug  6 17:04:50 2004
Subject: [jdom-interest] ID and IDREF
Message-ID: <MFFEPMMIAENICAAA@hotbot.com>

 Hi 

Sorry for the delay in answer. I think I need exactly what my friend has said. I f i encounter IDREF I should be able to get XML element which refers to the that IDREF and parameter will be value of idref attribute. By that way I will able to cross reference XML objects
Thanks
VS

--

On Tue, 05 Sep 2000 18:07:25   Brett McLaughlin wrote:
>
>
>veerpal singh wrote:
>> 
>> Hi All
>> 
>> I was just looking around on net for ID and IDREF processing. Is it possible thru jdom that when idref is encountered, element having iD can be retrieved. Or has to be done by higher level appl.
>
>What do you need to be able to do, and what would you expect the API to
>look like? Finally, what's your use-case for these changes.
>
>Let us know, and I'll look at what it would take to do.
>
>-Brett
>
>> 
>> Thanks
>> VS
>> 
>> HotBot - Search smarter.
>> http://www.hotbot.com
>> _______________________________________________
>> To control your jdom-interest membership:
>> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
>
>-- 
>Brett McLaughlin, Enhydra Strategist
>Lutris Technologies, Inc. 
>1200 Pacific Avenue, Suite 300 
>Santa Cruz, CA 95060 USA 
>http://www.lutris.com
>http://www.enhydra.org
>


HotBot - Search smarter.
http://www.hotbot.com

From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:50 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:50 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From veerpal at hotbot.com  Fri Sep  8 12:12:39 2000
From: veerpal at hotbot.com (veerpal singh)
Date: Fri Aug  6 17:04:50 2004
Subject: [jdom-interest] ID and IDREF
Message-ID: <MFFEPMMIAENICAAA@hotbot.com>

 Hi 

Sorry for the delay in answer. I think I need exactly what my friend has said. I f i encounter IDREF I should be able to get XML element which refers to the that IDREF and parameter will be value of idref attribute. By that way I will able to cross reference XML objects
Thanks
VS

--

On Tue, 05 Sep 2000 18:07:25   Brett McLaughlin wrote:
>
>
>veerpal singh wrote:
>> 
>> Hi All
>> 
>> I was just looking around on net for ID and IDREF processing. Is it possible thru jdom that when idref is encountered, element having iD can be retrieved. Or has to be done by higher level appl.
>
>What do you need to be able to do, and what would you expect the API to
>look like? Finally, what's your use-case for these changes.
>
>Let us know, and I'll look at what it would take to do.
>
>-Brett
>
>> 
>> Thanks
>> VS
>> 
>> HotBot - Search smarter.
>> http://www.hotbot.com
>> _______________________________________________
>> To control your jdom-interest membership:
>> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
>
>-- 
>Brett McLaughlin, Enhydra Strategist
>Lutris Technologies, Inc. 
>1200 Pacific Avenue, Suite 300 
>Santa Cruz, CA 95060 USA 
>http://www.lutris.com
>http://www.enhydra.org
>


HotBot - Search smarter.
http://www.hotbot.com

From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:50 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:50 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From veerpal at hotbot.com  Fri Sep  8 12:12:39 2000
From: veerpal at hotbot.com (veerpal singh)
Date: Fri Aug  6 17:04:50 2004
Subject: [jdom-interest] ID and IDREF
Message-ID: <MFFEPMMIAENICAAA@hotbot.com>

 Hi 

Sorry for the delay in answer. I think I need exactly what my friend has said. I f i encounter IDREF I should be able to get XML element which refers to the that IDREF and parameter will be value of idref attribute. By that way I will able to cross reference XML objects
Thanks
VS

--

On Tue, 05 Sep 2000 18:07:25   Brett McLaughlin wrote:
>
>
>veerpal singh wrote:
>> 
>> Hi All
>> 
>> I was just looking around on net for ID and IDREF processing. Is it possible thru jdom that when idref is encountered, element having iD can be retrieved. Or has to be done by higher level appl.
>
>What do you need to be able to do, and what would you expect the API to
>look like? Finally, what's your use-case for these changes.
>
>Let us know, and I'll look at what it would take to do.
>
>-Brett
>
>> 
>> Thanks
>> VS
>> 
>> HotBot - Search smarter.
>> http://www.hotbot.com
>> _______________________________________________
>> To control your jdom-interest membership:
>> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
>
>-- 
>Brett McLaughlin, Enhydra Strategist
>Lutris Technologies, Inc. 
>1200 Pacific Avenue, Suite 300 
>Santa Cruz, CA 95060 USA 
>http://www.lutris.com
>http://www.enhydra.org
>


HotBot - Search smarter.
http://www.hotbot.com

From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:50 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:50 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From veerpal at hotbot.com  Fri Sep  8 12:12:39 2000
From: veerpal at hotbot.com (veerpal singh)
Date: Fri Aug  6 17:04:50 2004
Subject: [jdom-interest] ID and IDREF
Message-ID: <MFFEPMMIAENICAAA@hotbot.com>

 Hi 

Sorry for the delay in answer. I think I need exactly what my friend has said. I f i encounter IDREF I should be able to get XML element which refers to the that IDREF and parameter will be value of idref attribute. By that way I will able to cross reference XML objects
Thanks
VS

--

On Tue, 05 Sep 2000 18:07:25   Brett McLaughlin wrote:
>
>
>veerpal singh wrote:
>> 
>> Hi All
>> 
>> I was just looking around on net for ID and IDREF processing. Is it possible thru jdom that when idref is encountered, element having iD can be retrieved. Or has to be done by higher level appl.
>
>What do you need to be able to do, and what would you expect the API to
>look like? Finally, what's your use-case for these changes.
>
>Let us know, and I'll look at what it would take to do.
>
>-Brett
>
>> 
>> Thanks
>> VS
>> 
>> HotBot - Search smarter.
>> http://www.hotbot.com
>> _______________________________________________
>> To control your jdom-interest membership:
>> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
>
>-- 
>Brett McLaughlin, Enhydra Strategist
>Lutris Technologies, Inc. 
>1200 Pacific Avenue, Suite 300 
>Santa Cruz, CA 95060 USA 
>http://www.lutris.com
>http://www.enhydra.org
>


HotBot - Search smarter.
http://www.hotbot.com

From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:50 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:50 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From veerpal at hotbot.com  Fri Sep  8 12:12:39 2000
From: veerpal at hotbot.com (veerpal singh)
Date: Fri Aug  6 17:04:50 2004
Subject: [jdom-interest] ID and IDREF
Message-ID: <MFFEPMMIAENICAAA@hotbot.com>

 Hi 

Sorry for the delay in answer. I think I need exactly what my friend has said. I f i encounter IDREF I should be able to get XML element which refers to the that IDREF and parameter will be value of idref attribute. By that way I will able to cross reference XML objects
Thanks
VS

--

On Tue, 05 Sep 2000 18:07:25   Brett McLaughlin wrote:
>
>
>veerpal singh wrote:
>> 
>> Hi All
>> 
>> I was just looking around on net for ID and IDREF processing. Is it possible thru jdom that when idref is encountered, element having iD can be retrieved. Or has to be done by higher level appl.
>
>What do you need to be able to do, and what would you expect the API to
>look like? Finally, what's your use-case for these changes.
>
>Let us know, and I'll look at what it would take to do.
>
>-Brett
>
>> 
>> Thanks
>> VS
>> 
>> HotBot - Search smarter.
>> http://www.hotbot.com
>> _______________________________________________
>> To control your jdom-interest membership:
>> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
>
>-- 
>Brett McLaughlin, Enhydra Strategist
>Lutris Technologies, Inc. 
>1200 Pacific Avenue, Suite 300 
>Santa Cruz, CA 95060 USA 
>http://www.lutris.com
>http://www.enhydra.org
>


HotBot - Search smarter.
http://www.hotbot.com

From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:50 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:50 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From veerpal at hotbot.com  Fri Sep  8 12:12:39 2000
From: veerpal at hotbot.com (veerpal singh)
Date: Fri Aug  6 17:04:50 2004
Subject: [jdom-interest] ID and IDREF
Message-ID: <MFFEPMMIAENICAAA@hotbot.com>

 Hi 

Sorry for the delay in answer. I think I need exactly what my friend has said. I f i encounter IDREF I should be able to get XML element which refers to the that IDREF and parameter will be value of idref attribute. By that way I will able to cross reference XML objects
Thanks
VS

--

On Tue, 05 Sep 2000 18:07:25   Brett McLaughlin wrote:
>
>
>veerpal singh wrote:
>> 
>> Hi All
>> 
>> I was just looking around on net for ID and IDREF processing. Is it possible thru jdom that when idref is encountered, element having iD can be retrieved. Or has to be done by higher level appl.
>
>What do you need to be able to do, and what would you expect the API to
>look like? Finally, what's your use-case for these changes.
>
>Let us know, and I'll look at what it would take to do.
>
>-Brett
>
>> 
>> Thanks
>> VS
>> 
>> HotBot - Search smarter.
>> http://www.hotbot.com
>> _______________________________________________
>> To control your jdom-interest membership:
>> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
>
>-- 
>Brett McLaughlin, Enhydra Strategist
>Lutris Technologies, Inc. 
>1200 Pacific Avenue, Suite 300 
>Santa Cruz, CA 95060 USA 
>http://www.lutris.com
>http://www.enhydra.org
>


HotBot - Search smarter.
http://www.hotbot.com

From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:50 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:50 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From veerpal at hotbot.com  Fri Sep  8 12:12:39 2000
From: veerpal at hotbot.com (veerpal singh)
Date: Fri Aug  6 17:04:50 2004
Subject: [jdom-interest] ID and IDREF
Message-ID: <MFFEPMMIAENICAAA@hotbot.com>

 Hi 

Sorry for the delay in answer. I think I need exactly what my friend has said. I f i encounter IDREF I should be able to get XML element which refers to the that IDREF and parameter will be value of idref attribute. By that way I will able to cross reference XML objects
Thanks
VS

--

On Tue, 05 Sep 2000 18:07:25   Brett McLaughlin wrote:
>
>
>veerpal singh wrote:
>> 
>> Hi All
>> 
>> I was just looking around on net for ID and IDREF processing. Is it possible thru jdom that when idref is encountered, element having iD can be retrieved. Or has to be done by higher level appl.
>
>What do you need to be able to do, and what would you expect the API to
>look like? Finally, what's your use-case for these changes.
>
>Let us know, and I'll look at what it would take to do.
>
>-Brett
>
>> 
>> Thanks
>> VS
>> 
>> HotBot - Search smarter.
>> http://www.hotbot.com
>> _______________________________________________
>> To control your jdom-interest membership:
>> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
>
>-- 
>Brett McLaughlin, Enhydra Strategist
>Lutris Technologies, Inc. 
>1200 Pacific Avenue, Suite 300 
>Santa Cruz, CA 95060 USA 
>http://www.lutris.com
>http://www.enhydra.org
>


HotBot - Search smarter.
http://www.hotbot.com

From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:50 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:50 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From veerpal at hotbot.com  Fri Sep  8 12:12:39 2000
From: veerpal at hotbot.com (veerpal singh)
Date: Fri Aug  6 17:04:50 2004
Subject: [jdom-interest] ID and IDREF
Message-ID: <MFFEPMMIAENICAAA@hotbot.com>

 Hi 

Sorry for the delay in answer. I think I need exactly what my friend has said. I f i encounter IDREF I should be able to get XML element which refers to the that IDREF and parameter will be value of idref attribute. By that way I will able to cross reference XML objects
Thanks
VS

--

On Tue, 05 Sep 2000 18:07:25   Brett McLaughlin wrote:
>
>
>veerpal singh wrote:
>> 
>> Hi All
>> 
>> I was just looking around on net for ID and IDREF processing. Is it possible thru jdom that when idref is encountered, element having iD can be retrieved. Or has to be done by higher level appl.
>
>What do you need to be able to do, and what would you expect the API to
>look like? Finally, what's your use-case for these changes.
>
>Let us know, and I'll look at what it would take to do.
>
>-Brett
>
>> 
>> Thanks
>> VS
>> 
>> HotBot - Search smarter.
>> http://www.hotbot.com
>> _______________________________________________
>> To control your jdom-interest membership:
>> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
>
>-- 
>Brett McLaughlin, Enhydra Strategist
>Lutris Technologies, Inc. 
>1200 Pacific Avenue, Suite 300 
>Santa Cruz, CA 95060 USA 
>http://www.lutris.com
>http://www.enhydra.org
>


HotBot - Search smarter.
http://www.hotbot.com

From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:50 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:50 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From veerpal at hotbot.com  Fri Sep  8 12:12:39 2000
From: veerpal at hotbot.com (veerpal singh)
Date: Fri Aug  6 17:04:50 2004
Subject: [jdom-interest] ID and IDREF
Message-ID: <MFFEPMMIAENICAAA@hotbot.com>

 Hi 

Sorry for the delay in answer. I think I need exactly what my friend has said. I f i encounter IDREF I should be able to get XML element which refers to the that IDREF and parameter will be value of idref attribute. By that way I will able to cross reference XML objects
Thanks
VS

--

On Tue, 05 Sep 2000 18:07:25   Brett McLaughlin wrote:
>
>
>veerpal singh wrote:
>> 
>> Hi All
>> 
>> I was just looking around on net for ID and IDREF processing. Is it possible thru jdom that when idref is encountered, element having iD can be retrieved. Or has to be done by higher level appl.
>
>What do you need to be able to do, and what would you expect the API to
>look like? Finally, what's your use-case for these changes.
>
>Let us know, and I'll look at what it would take to do.
>
>-Brett
>
>> 
>> Thanks
>> VS
>> 
>> HotBot - Search smarter.
>> http://www.hotbot.com
>> _______________________________________________
>> To control your jdom-interest membership:
>> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
>
>-- 
>Brett McLaughlin, Enhydra Strategist
>Lutris Technologies, Inc. 
>1200 Pacific Avenue, Suite 300 
>Santa Cruz, CA 95060 USA 
>http://www.lutris.com
>http://www.enhydra.org
>


HotBot - Search smarter.
http://www.hotbot.com

From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:51 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:51 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From veerpal at hotbot.com  Fri Sep  8 12:12:39 2000
From: veerpal at hotbot.com (veerpal singh)
Date: Fri Aug  6 17:04:51 2004
Subject: [jdom-interest] ID and IDREF
Message-ID: <MFFEPMMIAENICAAA@hotbot.com>

 Hi 

Sorry for the delay in answer. I think I need exactly what my friend has said. I f i encounter IDREF I should be able to get XML element which refers to the that IDREF and parameter will be value of idref attribute. By that way I will able to cross reference XML objects
Thanks
VS

--

On Tue, 05 Sep 2000 18:07:25   Brett McLaughlin wrote:
>
>
>veerpal singh wrote:
>> 
>> Hi All
>> 
>> I was just looking around on net for ID and IDREF processing. Is it possible thru jdom that when idref is encountered, element having iD can be retrieved. Or has to be done by higher level appl.
>
>What do you need to be able to do, and what would you expect the API to
>look like? Finally, what's your use-case for these changes.
>
>Let us know, and I'll look at what it would take to do.
>
>-Brett
>
>> 
>> Thanks
>> VS
>> 
>> HotBot - Search smarter.
>> http://www.hotbot.com
>> _______________________________________________
>> To control your jdom-interest membership:
>> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
>
>-- 
>Brett McLaughlin, Enhydra Strategist
>Lutris Technologies, Inc. 
>1200 Pacific Avenue, Suite 300 
>Santa Cruz, CA 95060 USA 
>http://www.lutris.com
>http://www.enhydra.org
>


HotBot - Search smarter.
http://www.hotbot.com

From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:51 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:51 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From veerpal at hotbot.com  Fri Sep  8 12:12:39 2000
From: veerpal at hotbot.com (veerpal singh)
Date: Fri Aug  6 17:04:51 2004
Subject: [jdom-interest] ID and IDREF
Message-ID: <MFFEPMMIAENICAAA@hotbot.com>

 Hi 

Sorry for the delay in answer. I think I need exactly what my friend has said. I f i encounter IDREF I should be able to get XML element which refers to the that IDREF and parameter will be value of idref attribute. By that way I will able to cross reference XML objects
Thanks
VS

--

On Tue, 05 Sep 2000 18:07:25   Brett McLaughlin wrote:
>
>
>veerpal singh wrote:
>> 
>> Hi All
>> 
>> I was just looking around on net for ID and IDREF processing. Is it possible thru jdom that when idref is encountered, element having iD can be retrieved. Or has to be done by higher level appl.
>
>What do you need to be able to do, and what would you expect the API to
>look like? Finally, what's your use-case for these changes.
>
>Let us know, and I'll look at what it would take to do.
>
>-Brett
>
>> 
>> Thanks
>> VS
>> 
>> HotBot - Search smarter.
>> http://www.hotbot.com
>> _______________________________________________
>> To control your jdom-interest membership:
>> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
>
>-- 
>Brett McLaughlin, Enhydra Strategist
>Lutris Technologies, Inc. 
>1200 Pacific Avenue, Suite 300 
>Santa Cruz, CA 95060 USA 
>http://www.lutris.com
>http://www.enhydra.org
>


HotBot - Search smarter.
http://www.hotbot.com

From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:51 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:51 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From veerpal at hotbot.com  Fri Sep  8 12:12:39 2000
From: veerpal at hotbot.com (veerpal singh)
Date: Fri Aug  6 17:04:51 2004
Subject: [jdom-interest] ID and IDREF
Message-ID: <MFFEPMMIAENICAAA@hotbot.com>

 Hi 

Sorry for the delay in answer. I think I need exactly what my friend has said. I f i encounter IDREF I should be able to get XML element which refers to the that IDREF and parameter will be value of idref attribute. By that way I will able to cross reference XML objects
Thanks
VS

--

On Tue, 05 Sep 2000 18:07:25   Brett McLaughlin wrote:
>
>
>veerpal singh wrote:
>> 
>> Hi All
>> 
>> I was just looking around on net for ID and IDREF processing. Is it possible thru jdom that when idref is encountered, element having iD can be retrieved. Or has to be done by higher level appl.
>
>What do you need to be able to do, and what would you expect the API to
>look like? Finally, what's your use-case for these changes.
>
>Let us know, and I'll look at what it would take to do.
>
>-Brett
>
>> 
>> Thanks
>> VS
>> 
>> HotBot - Search smarter.
>> http://www.hotbot.com
>> _______________________________________________
>> To control your jdom-interest membership:
>> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
>
>-- 
>Brett McLaughlin, Enhydra Strategist
>Lutris Technologies, Inc. 
>1200 Pacific Avenue, Suite 300 
>Santa Cruz, CA 95060 USA 
>http://www.lutris.com
>http://www.enhydra.org
>


HotBot - Search smarter.
http://www.hotbot.com

From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:51 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:51 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From veerpal at hotbot.com  Fri Sep  8 12:12:39 2000
From: veerpal at hotbot.com (veerpal singh)
Date: Fri Aug  6 17:04:51 2004
Subject: [jdom-interest] ID and IDREF
Message-ID: <MFFEPMMIAENICAAA@hotbot.com>

 Hi 

Sorry for the delay in answer. I think I need exactly what my friend has said. I f i encounter IDREF I should be able to get XML element which refers to the that IDREF and parameter will be value of idref attribute. By that way I will able to cross reference XML objects
Thanks
VS

--

On Tue, 05 Sep 2000 18:07:25   Brett McLaughlin wrote:
>
>
>veerpal singh wrote:
>> 
>> Hi All
>> 
>> I was just looking around on net for ID and IDREF processing. Is it possible thru jdom that when idref is encountered, element having iD can be retrieved. Or has to be done by higher level appl.
>
>What do you need to be able to do, and what would you expect the API to
>look like? Finally, what's your use-case for these changes.
>
>Let us know, and I'll look at what it would take to do.
>
>-Brett
>
>> 
>> Thanks
>> VS
>> 
>> HotBot - Search smarter.
>> http://www.hotbot.com
>> _______________________________________________
>> To control your jdom-interest membership:
>> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
>
>-- 
>Brett McLaughlin, Enhydra Strategist
>Lutris Technologies, Inc. 
>1200 Pacific Avenue, Suite 300 
>Santa Cruz, CA 95060 USA 
>http://www.lutris.com
>http://www.enhydra.org
>


HotBot - Search smarter.
http://www.hotbot.com

From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:51 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:51 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From veerpal at hotbot.com  Fri Sep  8 12:12:39 2000
From: veerpal at hotbot.com (veerpal singh)
Date: Fri Aug  6 17:04:51 2004
Subject: [jdom-interest] ID and IDREF
Message-ID: <MFFEPMMIAENICAAA@hotbot.com>

 Hi 

Sorry for the delay in answer. I think I need exactly what my friend has said. I f i encounter IDREF I should be able to get XML element which refers to the that IDREF and parameter will be value of idref attribute. By that way I will able to cross reference XML objects
Thanks
VS

--

On Tue, 05 Sep 2000 18:07:25   Brett McLaughlin wrote:
>
>
>veerpal singh wrote:
>> 
>> Hi All
>> 
>> I was just looking around on net for ID and IDREF processing. Is it possible thru jdom that when idref is encountered, element having iD can be retrieved. Or has to be done by higher level appl.
>
>What do you need to be able to do, and what would you expect the API to
>look like? Finally, what's your use-case for these changes.
>
>Let us know, and I'll look at what it would take to do.
>
>-Brett
>
>> 
>> Thanks
>> VS
>> 
>> HotBot - Search smarter.
>> http://www.hotbot.com
>> _______________________________________________
>> To control your jdom-interest membership:
>> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
>
>-- 
>Brett McLaughlin, Enhydra Strategist
>Lutris Technologies, Inc. 
>1200 Pacific Avenue, Suite 300 
>Santa Cruz, CA 95060 USA 
>http://www.lutris.com
>http://www.enhydra.org
>


HotBot - Search smarter.
http://www.hotbot.com

From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:51 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:51 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From veerpal at hotbot.com  Fri Sep  8 12:12:39 2000
From: veerpal at hotbot.com (veerpal singh)
Date: Fri Aug  6 17:04:51 2004
Subject: [jdom-interest] ID and IDREF
Message-ID: <MFFEPMMIAENICAAA@hotbot.com>

 Hi 

Sorry for the delay in answer. I think I need exactly what my friend has said. I f i encounter IDREF I should be able to get XML element which refers to the that IDREF and parameter will be value of idref attribute. By that way I will able to cross reference XML objects
Thanks
VS

--

On Tue, 05 Sep 2000 18:07:25   Brett McLaughlin wrote:
>
>
>veerpal singh wrote:
>> 
>> Hi All
>> 
>> I was just looking around on net for ID and IDREF processing. Is it possible thru jdom that when idref is encountered, element having iD can be retrieved. Or has to be done by higher level appl.
>
>What do you need to be able to do, and what would you expect the API to
>look like? Finally, what's your use-case for these changes.
>
>Let us know, and I'll look at what it would take to do.
>
>-Brett
>
>> 
>> Thanks
>> VS
>> 
>> HotBot - Search smarter.
>> http://www.hotbot.com
>> _______________________________________________
>> To control your jdom-interest membership:
>> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
>
>-- 
>Brett McLaughlin, Enhydra Strategist
>Lutris Technologies, Inc. 
>1200 Pacific Avenue, Suite 300 
>Santa Cruz, CA 95060 USA 
>http://www.lutris.com
>http://www.enhydra.org
>


HotBot - Search smarter.
http://www.hotbot.com

From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:51 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:51 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From veerpal at hotbot.com  Fri Sep  8 12:12:39 2000
From: veerpal at hotbot.com (veerpal singh)
Date: Fri Aug  6 17:04:51 2004
Subject: [jdom-interest] ID and IDREF
Message-ID: <MFFEPMMIAENICAAA@hotbot.com>

 Hi 

Sorry for the delay in answer. I think I need exactly what my friend has said. I f i encounter IDREF I should be able to get XML element which refers to the that IDREF and parameter will be value of idref attribute. By that way I will able to cross reference XML objects
Thanks
VS

--

On Tue, 05 Sep 2000 18:07:25   Brett McLaughlin wrote:
>
>
>veerpal singh wrote:
>> 
>> Hi All
>> 
>> I was just looking around on net for ID and IDREF processing. Is it possible thru jdom that when idref is encountered, element having iD can be retrieved. Or has to be done by higher level appl.
>
>What do you need to be able to do, and what would you expect the API to
>look like? Finally, what's your use-case for these changes.
>
>Let us know, and I'll look at what it would take to do.
>
>-Brett
>
>> 
>> Thanks
>> VS
>> 
>> HotBot - Search smarter.
>> http://www.hotbot.com
>> _______________________________________________
>> To control your jdom-interest membership:
>> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
>
>-- 
>Brett McLaughlin, Enhydra Strategist
>Lutris Technologies, Inc. 
>1200 Pacific Avenue, Suite 300 
>Santa Cruz, CA 95060 USA 
>http://www.lutris.com
>http://www.enhydra.org
>


HotBot - Search smarter.
http://www.hotbot.com

From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:51 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:51 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From veerpal at hotbot.com  Fri Sep  8 12:12:39 2000
From: veerpal at hotbot.com (veerpal singh)
Date: Fri Aug  6 17:04:51 2004
Subject: [jdom-interest] ID and IDREF
Message-ID: <MFFEPMMIAENICAAA@hotbot.com>

 Hi 

Sorry for the delay in answer. I think I need exactly what my friend has said. I f i encounter IDREF I should be able to get XML element which refers to the that IDREF and parameter will be value of idref attribute. By that way I will able to cross reference XML objects
Thanks
VS

--

On Tue, 05 Sep 2000 18:07:25   Brett McLaughlin wrote:
>
>
>veerpal singh wrote:
>> 
>> Hi All
>> 
>> I was just looking around on net for ID and IDREF processing. Is it possible thru jdom that when idref is encountered, element having iD can be retrieved. Or has to be done by higher level appl.
>
>What do you need to be able to do, and what would you expect the API to
>look like? Finally, what's your use-case for these changes.
>
>Let us know, and I'll look at what it would take to do.
>
>-Brett
>
>> 
>> Thanks
>> VS
>> 
>> HotBot - Search smarter.
>> http://www.hotbot.com
>> _______________________________________________
>> To control your jdom-interest membership:
>> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
>
>-- 
>Brett McLaughlin, Enhydra Strategist
>Lutris Technologies, Inc. 
>1200 Pacific Avenue, Suite 300 
>Santa Cruz, CA 95060 USA 
>http://www.lutris.com
>http://www.enhydra.org
>


HotBot - Search smarter.
http://www.hotbot.com

From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:51 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:51 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From veerpal at hotbot.com  Fri Sep  8 12:12:39 2000
From: veerpal at hotbot.com (veerpal singh)
Date: Fri Aug  6 17:04:51 2004
Subject: [jdom-interest] ID and IDREF
Message-ID: <MFFEPMMIAENICAAA@hotbot.com>

 Hi 

Sorry for the delay in answer. I think I need exactly what my friend has said. I f i encounter IDREF I should be able to get XML element which refers to the that IDREF and parameter will be value of idref attribute. By that way I will able to cross reference XML objects
Thanks
VS

--

On Tue, 05 Sep 2000 18:07:25   Brett McLaughlin wrote:
>
>
>veerpal singh wrote:
>> 
>> Hi All
>> 
>> I was just looking around on net for ID and IDREF processing. Is it possible thru jdom that when idref is encountered, element having iD can be retrieved. Or has to be done by higher level appl.
>
>What do you need to be able to do, and what would you expect the API to
>look like? Finally, what's your use-case for these changes.
>
>Let us know, and I'll look at what it would take to do.
>
>-Brett
>
>> 
>> Thanks
>> VS
>> 
>> HotBot - Search smarter.
>> http://www.hotbot.com
>> _______________________________________________
>> To control your jdom-interest membership:
>> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
>
>-- 
>Brett McLaughlin, Enhydra Strategist
>Lutris Technologies, Inc. 
>1200 Pacific Avenue, Suite 300 
>Santa Cruz, CA 95060 USA 
>http://www.lutris.com
>http://www.enhydra.org
>


HotBot - Search smarter.
http://www.hotbot.com

From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:51 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:51 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From veerpal at hotbot.com  Fri Sep  8 12:12:39 2000
From: veerpal at hotbot.com (veerpal singh)
Date: Fri Aug  6 17:04:51 2004
Subject: [jdom-interest] ID and IDREF
Message-ID: <MFFEPMMIAENICAAA@hotbot.com>

 Hi 

Sorry for the delay in answer. I think I need exactly what my friend has said. I f i encounter IDREF I should be able to get XML element which refers to the that IDREF and parameter will be value of idref attribute. By that way I will able to cross reference XML objects
Thanks
VS

--

On Tue, 05 Sep 2000 18:07:25   Brett McLaughlin wrote:
>
>
>veerpal singh wrote:
>> 
>> Hi All
>> 
>> I was just looking around on net for ID and IDREF processing. Is it possible thru jdom that when idref is encountered, element having iD can be retrieved. Or has to be done by higher level appl.
>
>What do you need to be able to do, and what would you expect the API to
>look like? Finally, what's your use-case for these changes.
>
>Let us know, and I'll look at what it would take to do.
>
>-Brett
>
>> 
>> Thanks
>> VS
>> 
>> HotBot - Search smarter.
>> http://www.hotbot.com
>> _______________________________________________
>> To control your jdom-interest membership:
>> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
>
>-- 
>Brett McLaughlin, Enhydra Strategist
>Lutris Technologies, Inc. 
>1200 Pacific Avenue, Suite 300 
>Santa Cruz, CA 95060 USA 
>http://www.lutris.com
>http://www.enhydra.org
>


HotBot - Search smarter.
http://www.hotbot.com

From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:51 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:51 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From veerpal at hotbot.com  Fri Sep  8 12:12:39 2000
From: veerpal at hotbot.com (veerpal singh)
Date: Fri Aug  6 17:04:51 2004
Subject: [jdom-interest] ID and IDREF
Message-ID: <MFFEPMMIAENICAAA@hotbot.com>

 Hi 

Sorry for the delay in answer. I think I need exactly what my friend has said. I f i encounter IDREF I should be able to get XML element which refers to the that IDREF and parameter will be value of idref attribute. By that way I will able to cross reference XML objects
Thanks
VS

--

On Tue, 05 Sep 2000 18:07:25   Brett McLaughlin wrote:
>
>
>veerpal singh wrote:
>> 
>> Hi All
>> 
>> I was just looking around on net for ID and IDREF processing. Is it possible thru jdom that when idref is encountered, element having iD can be retrieved. Or has to be done by higher level appl.
>
>What do you need to be able to do, and what would you expect the API to
>look like? Finally, what's your use-case for these changes.
>
>Let us know, and I'll look at what it would take to do.
>
>-Brett
>
>> 
>> Thanks
>> VS
>> 
>> HotBot - Search smarter.
>> http://www.hotbot.com
>> _______________________________________________
>> To control your jdom-interest membership:
>> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
>
>-- 
>Brett McLaughlin, Enhydra Strategist
>Lutris Technologies, Inc. 
>1200 Pacific Avenue, Suite 300 
>Santa Cruz, CA 95060 USA 
>http://www.lutris.com
>http://www.enhydra.org
>


HotBot - Search smarter.
http://www.hotbot.com

From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:51 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:51 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From veerpal at hotbot.com  Fri Sep  8 12:12:39 2000
From: veerpal at hotbot.com (veerpal singh)
Date: Fri Aug  6 17:04:51 2004
Subject: [jdom-interest] ID and IDREF
Message-ID: <MFFEPMMIAENICAAA@hotbot.com>

 Hi 

Sorry for the delay in answer. I think I need exactly what my friend has said. I f i encounter IDREF I should be able to get XML element which refers to the that IDREF and parameter will be value of idref attribute. By that way I will able to cross reference XML objects
Thanks
VS

--

On Tue, 05 Sep 2000 18:07:25   Brett McLaughlin wrote:
>
>
>veerpal singh wrote:
>> 
>> Hi All
>> 
>> I was just looking around on net for ID and IDREF processing. Is it possible thru jdom that when idref is encountered, element having iD can be retrieved. Or has to be done by higher level appl.
>
>What do you need to be able to do, and what would you expect the API to
>look like? Finally, what's your use-case for these changes.
>
>Let us know, and I'll look at what it would take to do.
>
>-Brett
>
>> 
>> Thanks
>> VS
>> 
>> HotBot - Search smarter.
>> http://www.hotbot.com
>> _______________________________________________
>> To control your jdom-interest membership:
>> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
>
>-- 
>Brett McLaughlin, Enhydra Strategist
>Lutris Technologies, Inc. 
>1200 Pacific Avenue, Suite 300 
>Santa Cruz, CA 95060 USA 
>http://www.lutris.com
>http://www.enhydra.org
>


HotBot - Search smarter.
http://www.hotbot.com

From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:51 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:51 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From veerpal at hotbot.com  Fri Sep  8 12:12:39 2000
From: veerpal at hotbot.com (veerpal singh)
Date: Fri Aug  6 17:04:51 2004
Subject: [jdom-interest] ID and IDREF
Message-ID: <MFFEPMMIAENICAAA@hotbot.com>

 Hi 

Sorry for the delay in answer. I think I need exactly what my friend has said. I f i encounter IDREF I should be able to get XML element which refers to the that IDREF and parameter will be value of idref attribute. By that way I will able to cross reference XML objects
Thanks
VS

--

On Tue, 05 Sep 2000 18:07:25   Brett McLaughlin wrote:
>
>
>veerpal singh wrote:
>> 
>> Hi All
>> 
>> I was just looking around on net for ID and IDREF processing. Is it possible thru jdom that when idref is encountered, element having iD can be retrieved. Or has to be done by higher level appl.
>
>What do you need to be able to do, and what would you expect the API to
>look like? Finally, what's your use-case for these changes.
>
>Let us know, and I'll look at what it would take to do.
>
>-Brett
>
>> 
>> Thanks
>> VS
>> 
>> HotBot - Search smarter.
>> http://www.hotbot.com
>> _______________________________________________
>> To control your jdom-interest membership:
>> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
>
>-- 
>Brett McLaughlin, Enhydra Strategist
>Lutris Technologies, Inc. 
>1200 Pacific Avenue, Suite 300 
>Santa Cruz, CA 95060 USA 
>http://www.lutris.com
>http://www.enhydra.org
>


HotBot - Search smarter.
http://www.hotbot.com

From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:51 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:51 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From veerpal at hotbot.com  Fri Sep  8 12:12:39 2000
From: veerpal at hotbot.com (veerpal singh)
Date: Fri Aug  6 17:04:51 2004
Subject: [jdom-interest] ID and IDREF
Message-ID: <MFFEPMMIAENICAAA@hotbot.com>

 Hi 

Sorry for the delay in answer. I think I need exactly what my friend has said. I f i encounter IDREF I should be able to get XML element which refers to the that IDREF and parameter will be value of idref attribute. By that way I will able to cross reference XML objects
Thanks
VS

--

On Tue, 05 Sep 2000 18:07:25   Brett McLaughlin wrote:
>
>
>veerpal singh wrote:
>> 
>> Hi All
>> 
>> I was just looking around on net for ID and IDREF processing. Is it possible thru jdom that when idref is encountered, element having iD can be retrieved. Or has to be done by higher level appl.
>
>What do you need to be able to do, and what would you expect the API to
>look like? Finally, what's your use-case for these changes.
>
>Let us know, and I'll look at what it would take to do.
>
>-Brett
>
>> 
>> Thanks
>> VS
>> 
>> HotBot - Search smarter.
>> http://www.hotbot.com
>> _______________________________________________
>> To control your jdom-interest membership:
>> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
>
>-- 
>Brett McLaughlin, Enhydra Strategist
>Lutris Technologies, Inc. 
>1200 Pacific Avenue, Suite 300 
>Santa Cruz, CA 95060 USA 
>http://www.lutris.com
>http://www.enhydra.org
>


HotBot - Search smarter.
http://www.hotbot.com

From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:51 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:51 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From veerpal at hotbot.com  Fri Sep  8 12:12:39 2000
From: veerpal at hotbot.com (veerpal singh)
Date: Fri Aug  6 17:04:51 2004
Subject: [jdom-interest] ID and IDREF
Message-ID: <MFFEPMMIAENICAAA@hotbot.com>

 Hi 

Sorry for the delay in answer. I think I need exactly what my friend has said. I f i encounter IDREF I should be able to get XML element which refers to the that IDREF and parameter will be value of idref attribute. By that way I will able to cross reference XML objects
Thanks
VS

--

On Tue, 05 Sep 2000 18:07:25   Brett McLaughlin wrote:
>
>
>veerpal singh wrote:
>> 
>> Hi All
>> 
>> I was just looking around on net for ID and IDREF processing. Is it possible thru jdom that when idref is encountered, element having iD can be retrieved. Or has to be done by higher level appl.
>
>What do you need to be able to do, and what would you expect the API to
>look like? Finally, what's your use-case for these changes.
>
>Let us know, and I'll look at what it would take to do.
>
>-Brett
>
>> 
>> Thanks
>> VS
>> 
>> HotBot - Search smarter.
>> http://www.hotbot.com
>> _______________________________________________
>> To control your jdom-interest membership:
>> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
>
>-- 
>Brett McLaughlin, Enhydra Strategist
>Lutris Technologies, Inc. 
>1200 Pacific Avenue, Suite 300 
>Santa Cruz, CA 95060 USA 
>http://www.lutris.com
>http://www.enhydra.org
>


HotBot - Search smarter.
http://www.hotbot.com

From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:51 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:51 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From veerpal at hotbot.com  Fri Sep  8 12:12:39 2000
From: veerpal at hotbot.com (veerpal singh)
Date: Fri Aug  6 17:04:51 2004
Subject: [jdom-interest] ID and IDREF
Message-ID: <MFFEPMMIAENICAAA@hotbot.com>

 Hi 

Sorry for the delay in answer. I think I need exactly what my friend has said. I f i encounter IDREF I should be able to get XML element which refers to the that IDREF and parameter will be value of idref attribute. By that way I will able to cross reference XML objects
Thanks
VS

--

On Tue, 05 Sep 2000 18:07:25   Brett McLaughlin wrote:
>
>
>veerpal singh wrote:
>> 
>> Hi All
>> 
>> I was just looking around on net for ID and IDREF processing. Is it possible thru jdom that when idref is encountered, element having iD can be retrieved. Or has to be done by higher level appl.
>
>What do you need to be able to do, and what would you expect the API to
>look like? Finally, what's your use-case for these changes.
>
>Let us know, and I'll look at what it would take to do.
>
>-Brett
>
>> 
>> Thanks
>> VS
>> 
>> HotBot - Search smarter.
>> http://www.hotbot.com
>> _______________________________________________
>> To control your jdom-interest membership:
>> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
>
>-- 
>Brett McLaughlin, Enhydra Strategist
>Lutris Technologies, Inc. 
>1200 Pacific Avenue, Suite 300 
>Santa Cruz, CA 95060 USA 
>http://www.lutris.com
>http://www.enhydra.org
>


HotBot - Search smarter.
http://www.hotbot.com

From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:51 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:51 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:51 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:51 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:51 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:51 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:51 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:51 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:51 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:51 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:51 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:51 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:51 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:51 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:51 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:51 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:52 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:53 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:54 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:54 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:54 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:54 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:54 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:54 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:54 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:54 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:54 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:54 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:54 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:54 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:54 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:54 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:54 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:54 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:54 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:54 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:54 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:54 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:54 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:54 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:54 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:54 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:54 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:54 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:54 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:54 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:54 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:54 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:54 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:54 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:54 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:54 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:54 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:54 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:54 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:54 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:54 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:54 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:54 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:54 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:54 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:54 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From traversw at innoforge.co.za  Fri Sep  8 04:27:03 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:55 2004
Subject: [jdom-interest] Validation using schemas, how?
Message-ID: <00bc01c01987$b79887c0$1501a8c0@travers>

Hi Jdom mailing list subscribers.

I'm struggling with validating with schemas using JDOM.  I'm  trying to get
a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
included what I think should work

I'm expecting this minimal test program to throw an exception because the
contents of <tag> is 1, and I thought I was constraining it to being an
integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
is, I get a message saying I must define the <tag> element.  specifying a
dtd sorts that out, but surely one doesn't have to use both a dtd and a
schema for validation - a schema on its own should be acceptable too.

BTW, the latest complete download of Jdom in the CVS repository does not
seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
becasue it didn't have Ant and Xerces in the lib directory.

I feel a bit bad about this post because it's more a newbie request for help
than a contribution towards the coding of Jdom.  Maybe it's time for a
jdom-help mailing list.

Thanks to anyone who can help.

Travers

File: test.xml

  <!DOCTYPE tag>
  <tag
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:schemaLocation="file://test.xsd">1</tag>

File: test.xsd

  <schema xmlns="http://www.w3.org/1999/XMLSchema">

  <dataType name="limitedInt">
    <basetype name="integer"/>
    <minInclusive>2</minInclusive>
  </dataType>

  <elementType name="tag">
    <datatypeRef name="limitedInt">
  </elementType>

File: JdomTest.java

package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder();  // SHOULD THIS HAVE "true" ARG
FOR SCHEMA VALIDATION?
    Document doc = builder.build(new File("test.xml"));

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}




From jeremiah at goodinassociates.com  Fri Sep  8 05:49:21 2000
From: jeremiah at goodinassociates.com (Jeremiah Jahn)
Date: Fri Aug  6 17:04:55 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <00090807593600.20305@jeremiah>

	I was wondering if it would be a good idea to specify our own serialVersionUID's
The reason being that currently with all of the development, and an unknown time till 1.0 it's quite difficult to use jdom for object persistence.
I would think that the variables used in most of the classes that would be used (Element Attribute etc.)  are pretty stable by now?
I can always use DOM as the persistant object, but I'd like to skip the overhead..

	Is this a possibility?

-jj-


From mengelhart at earthtrip.com  Fri Sep  8 18:28:46 2000
From: mengelhart at earthtrip.com (Michael Engelhart)
Date: Fri Aug  6 17:04:55 2004
Subject: [jdom-interest] question (help)
Message-ID: <069483430010990SM1@mail.austin.rr.com>

Awesome - thanks!

Mike

> Michael Engelhart wrote:
> >
> > Hi,
> >
> > Yesterday I posted about a problem I'm having with the
> > getAttributeValue(String name) method in the Element class which I didn't 
> > get a response to so I'm reposting since my question may not have been very 
> > clear.  Here goes:
> > If I have an attribute value which is an "escaped" string, the escape
> > slash is removed upon retrieval.  Can anyone tell me if this is a bug or 
> > expected behavior?  If it's expected, please tell me why that happens so I 
> > can try and come up with a workaround.  The reason (in case anyone is
> > questioning) that I have escaped strings is that i'm keeping a bunch of 
> > regular expressions stored in an xml document for retrieval and am using 
> > the ORO (now Apache) Perl utilities matching classes which require escaped 
> > strings in their patterns like this:
> > m/MAX\\s+([0-9]+)/s
> >
> > which the getAttributeValue() mangles into:
> > m/MAX\s+([0-9]+)/s
> >
> > not the single slash after "MAX" in the returned string.   I can't figure 
> > out why this would be the correct behavior but maybe it is.
>
> Hey, Mike-
>
>   For sure, it's a bug. I've got it pn my list to look at and just
> haven't gotten a chance yet ... I'll try to fix that this weekend. Sorry 
> for the delay in a response ;-)
>
> -Brett
>

From bob at accurev.com  Fri Sep  8 19:30:46 2000
From: bob at accurev.com (bob)
Date: Fri Aug  6 17:04:55 2004
Subject: [jdom-interest] XPath snapshot
Message-ID: <Pine.LNX.3.96.1000908222343.7232O-100000@exeter.exeter.org>

Howdy guys--

My XPath work has (temporarily) moved out of jdom-contrib,
due to an overload of Very Confused Files (Michael Hinchey
and I tripped over each other 1-too-many times.)

A snapshot is now available.  It includes jdom.jar (a relatively 
recent snapshot) and xerces.jar (from the JDOM lib/ directory).

Additionally, javadocs have been generated for most classes
of interest.

Right now, with all included .jars, pre-compiled werken.xpath.jar,
and javadoc HTML documentation, the snapshot is ~1.4MB.

Once JDOM itself stabilizes, and we have a reference release,
this of course will shrink.

It is still woefully incomplete, with regards to:

	a) Core XPath function library
	b) Document-order of elements
	c) Anything that's a direct peer/sibling of the 
	   root element of the document.

Relative & absolute location paths work.  Filter-expressions work.
Predicates work.  (Though, there may be some funkiness, of course.)

For now, I'm keeping it in the com.werken.xpath package, and
will provide snapshots regularly.  Though, it's under the ASF
license, so feel free to steal/integrate it into whatever you
like.  I forsee it returning to the jdom-contrib CVS sometime
in the future.

Anyhow...

  Tarball:

	http://code.werken.com/xpath/werken.xpath.tar.gz

  Browsable distribution:

	http://code.werken.com/xpath/werken.xpath/

  API Docs:

	http://code.werken.com/xpath/werken.xpath/build/apidocs/

		-bob
		(honestly, I'm only sending this once,
		in case you get 6 bazillion copies of it.)


From jhunter at collab.net  Fri Sep  8 20:03:28 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:04:55 2004
Subject: [jdom-interest] DOMOutputter API change
Message-ID: <39B9A880.29EDC78D@collab.net>

Hi everyone,

I just checked in an enhancement to DOMOutputter that adds an 

Attr DOMOutputter.output(Attribute) 

method thanks to Yusuf Goolamabbas.  It's prob not as generally useful
as the versions taking Document and Element but theoretically could come
in handy.  I'm interested in your opinion on whether it should remain,
and furthermore if we should have PI, Comment, and CDATA output()
methods as well to be consistent?

BIG NOTE:  As part of this I also changed the output() methods so they
now throw JDOMException in case of problems.  This is INCOMPATIBLE with
the old signature that threw no exceptions (just printed the stack
trace, not the right thing for a library to do), so make sure to update
any code using DOMOutputter if you're tracking the daily progress.

-jh-

From jhunter at collab.net  Fri Sep  8 20:19:05 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:04:55 2004
Subject: [jdom-interest] Multiple copies
Message-ID: <39B9AC29.B5A2AD77@collab.net>

Some of you may be getting multiple copies of some recent messages.  My
best guess is Mailman has a bug where manually approved non-subscriber
posts are sent out multiple times.  This happened (to me at least, some
people only saw a single message) earlier in the week but fortunately
stopped after about 12 duplicates.  :-)  I sent a note to our hosting
company, to see if they did an upgrade or something that might cause
this new problem.  If anyone of you are Mailman gurus and know about
this kind of thing, let me know.

-jh-

From david at adlibsys.co.uk  Thu Sep  7 23:32:30 2000
From: david at adlibsys.co.uk (David M. Lang)
Date: Fri Aug  6 17:04:55 2004
Subject: [jdom-interest] Document and RMI
Message-ID: <000201c01a33$238cd3e0$0a64a8c0@xpst450>

Hi,

A quick question. I'd like to use XML to provide an extensible method
argument list, in a manner analagous to XML-RPC, but less formalised. The
intention is to represent the XML argument list as a JDOM document, and pass
this to a remote Java object, as follows:

public interface Service extends java.rmi.Remote
{
  public Document request(Document doc) throws RemoteException;
}

The problem is that I get a run-time java.rmi.MarshalException, complaining
that Namespace isn't serializable. Making Namespace subscribe to the
java.io.Serializable marker interface fixes the problem.

However, I'm surely missing something. Is this an efficient way to do this?
Should I convert the Document to a String argument and pass that? Or should
I subclass Document, and make it a remote object?

Any help greatly appreciated. Thanks in advance.
(I'm using JDOM Beta 4)

David Lang




From johan.dahlstrom at RKS.SE  Sat Sep  9 07:17:09 2000
From: johan.dahlstrom at RKS.SE (=?iso-8859-1?Q?Johan_Dahlstr=F6m?=)
Date: Fri Aug  6 17:04:55 2004
Subject: [jdom-interest] serialVersionUID/Re: [jdom-interest] ID and IDRE
	F  /[jdom-interest] Validation using schemas, how?  
Message-ID: <3E57E9B10918D411A28500A0C9A57819B3CB47@NTRKS1.rks.se>

[jdom-interest] serialVersionUID
Re: [jdom-interest] ID and IDREF
[jdom-interest] Validation using schemas, how?  

I've got a _lot_ of these messages, and it seems like the listserver has
gone sour more than once in the last days. Is it possible that someone can
fix this?

Regards
Johan Dahlstrom



From joerg at freiheit.com  Mon Sep 11 08:18:04 2000
From: joerg at freiheit.com (Joerg)
Date: Fri Aug  6 17:04:55 2004
Subject: [jdom-interest] Multiple copies
References: <39B9AC29.B5A2AD77@collab.net>
Message-ID: <39BCF7AC.A5C1A182@freiheit.com>

I received over 150!  :-o copies of the messages from Jeremiah Jahn and Travers Waker
:-)

J?rg

Jason Hunter wrote:

> Some of you may be getting multiple copies of some recent messages.  My
> best guess is Mailman has a bug where manually approved non-subscriber
> posts are sent out multiple times.  This happened (to me at least, some
> people only saw a single message) earlier in the week but fortunately
> stopped after about 12 duplicates.  :-)  I sent a note to our hosting
> company, to see if they did an upgrade or something that might cause
> this new problem.  If anyone of you are Mailman gurus and know about
> this kind of thing, let me know.
>
> -jh-
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com




From Brad.Morgan at e-pubcorp.com  Mon Sep 11 09:18:59 2000
From: Brad.Morgan at e-pubcorp.com (Brad Morgan)
Date: Fri Aug  6 17:04:55 2004
Subject: [jdom-interest] SAXbuilder.build Behavior
In-Reply-To: <3E57E9B10918D411A28500A0C9A57819B3CB47@NTRKS1.rks.se>
Message-ID: <NDBBLFGNKKGCBIJEAIJBKEOICGAA.Brad.Morgan@e-pubcorp.com>

I have noticed that the Document built by the SAXbuilder is different
depending on the presence or absence of a <!DOCTYPE... in the input XML
file.

I have tried both:
SAXBuilder builder = new SAXBuilder();
and
SAXBuilder builder = new SAXBuilder(false);

With the <!DOCTYPE I get no white space in the JDOM Document tree and
without the <!DOCTYPE I get the white space in the tree.

After making my changes to the JDOM tree in memory, I now want to use
XMLOutputter to create a new document but of course the appropriate
parameters to use are dependant on which flavor of input I received.

Is this the expected behavior?  If so, what is the proper/best way to
determine how to call XMLOutputter?

Thanks for your prompt replies.

Brad Morgan
e-Publishing Corp.

Email: Brad.Morgan@e-pubcorp.com
Phone: (719)593-7377 x35
Fax: (719)593-2996

e-Publishing Corp. is a BroadVision company
NOTICE: This message is intended only for the use of the Addressee and may
contain information that is PRIVILEGED and CONFIDENTIAL. If you are not the
intended recipient, dissemination of this communication is prohibited. If
you have received this communication in error, please erase all copies of
the message and its attachments and notify us immediately.



From jhunter at collab.net  Mon Sep 11 10:22:32 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:04:55 2004
Subject: [jdom-interest] Document and RMI
References: <000201c01a33$238cd3e0$0a64a8c0@xpst450>
Message-ID: <39BD14D7.50D6766F@collab.net>

> (I'm using JDOM Beta 4)

If you use the latest code it'll work.

-jh-

From jhunter at collab.net  Mon Sep 11 10:54:41 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:04:55 2004
Subject: [jdom-interest] The list is back under control
Message-ID: <39BD1C61.B75C7ACA@collab.net>

OK, the jdom-interest list is back under control.  Here's the word from
DJ on the support staff.  Sorry for the email flood.

--
I think I've got the jdom-interest list back under control (as of about
1:00 AM). [I signed up for the list and at least I'm not getting
multiple copies.]  As a consequence of working on this, digests did NOT
go out at midnight.  They will resume tonight, and contain 2 days worth
of posts.

This is definitely a bug in Mailman 2.0b5.  (Which we upgraded in
mid-August to fix some queueing problems in the back end.) The bug is in
the program that runs from cron to re-attempt to deliver messages that
were previously "undeliverable" or had some sort of delivery error.

A fix was completed Friday, but has not been made available yet.  I'll
upgrade/patch mailman as soon as I can get my hands on the fix.  In the
meantime, I'll cut the cron job back to every 30 minutes from every 4
mins.  That should at least limit the volume of any recurrances.

I think I've got the offending messages cleared out of the system, but
they may pop up again.  Please let me know if they do.
--

-jh-

P.S.  Bet we had the most popular open source project over the weekend,
as measured by mailing list traffic.  :-)

P.P.S.  Until I get word this problem has been fixed I will approve no
non-subscriber posts.  Those are the posts that triggered this bug.  If
you want to post from an address that's not subscribed, see the FAQ for
instructions.

From sclark at e-numerate.com  Mon Sep 11 12:49:38 2000
From: sclark at e-numerate.com (Clark, Stacie)
Date: Fri Aug  6 17:04:55 2004
Subject: [jdom-interest] Default XMLOutputter behavior
Message-ID: <878F521262E9D31184FF00C0F047DEEE07349B@MAIL>

If I parse some xml that does not have a header, it's just a fragment of a
document, I see the following behavior:

SAXBuilder using XMLOutputer adds:
<?xml version="1.0" encoding="UTF-8"?>

DOMBuilder using XMLOutputter adds:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE SECTION> 

I would have expected the default output to look the same, since the
orignal text had no heading at all. (I know that the heading and doc
declaration can be explicitly turned on and off). 

Stacie

From chris.laprun at nist.gov  Sun Sep 10 10:28:18 2000
From: chris.laprun at nist.gov (Christophe D. Laprun)
Date: Fri Aug  6 17:04:55 2004
Subject: [jdom-interest] Validation using schemas, how?
References: <00bc01c01987$b79887c0$1501a8c0@travers>
Message-ID: <39BBC4B2.ADC43ED7@nist.gov>

Travers Waker wrote:
> 
> Hi Jdom mailing list subscribers.
> 
> I'm struggling with validating with schemas using JDOM.  I'm  trying to get
> a simple-as-can be schema to validate a simple-as-can-be XML doc.  I've
> included what I think should work
> 
> I'm expecting this minimal test program to throw an exception because the
> contents of <tag> is 1, and I thought I was constraining it to being an
> integer >= 2 in test.xsd.  It doesn't behave like I expected (no Exception
> is thrown).  Also, when I call "new SAXBuilder(true)" with my code like it
> is, I get a message saying I must define the <tag> element.  specifying a
> dtd sorts that out, but surely one doesn't have to use both a dtd and a
> schema for validation - a schema on its own should be acceptable too.
> 
> BTW, the latest complete download of Jdom in the CVS repository does not
> seem to be complete.  The jdom-complete.zip I downloaded wouldn't build
> becasue it didn't have Ant and Xerces in the lib directory.
> 
> I feel a bit bad about this post because it's more a newbie request for help
> than a contribution towards the coding of Jdom.  Maybe it's time for a
> jdom-help mailing list.
> 
> Thanks to anyone who can help.

I also struggled with namespaces and I found that in SAXBuilder the fact
that the "namespaces" feature is hardwired to false prevents
correct handling of schemas. Setting the property to true seemed to
solve
the problem. 

This is an issue that I brought to the list but no one answered.
Why is this property hardwired to false ? Why isn't there a way to
programmatically set the property ?


HTH,

Chris


-- 
Christophe Laprun    [Ingenieur ISIMA, France / Guest researcher @NIST]
web: http://www.nist.gov/speech/staff/laprunch.htm
email: chris.laprun@nist.gov
phone: (301) 975 3191             fax: (301) 670 0939
--
The universe seems neither benign nor hostile, merely indifferent -
Sagan

From kjetil at cs.stanford.edu  Sun Sep 10 17:02:31 2000
From: kjetil at cs.stanford.edu (Kjetil Larsen)
Date: Fri Aug  6 17:04:55 2004
Subject: [jdom-interest] xml:lang and compilation problems
Message-ID: <39BC2117.E3668594@cs.stanford.edu>

Hi,

I'm using the having problem using SAXBuilder with the Xerces to parse
xml documents with
attributes such as xml:lang. I read the FAQ threads on the issue (Stacie
Clark, Jason Hunter)
and gathered I needed the latest CVS build. This didn't solve the
problem, however. I'm still
getting:
org.xml.sax.SAXException: The name "xml" is not legal for JDOM/XML
Namespace pre
fixs: Namespace prefixes cannot begin with "xml" in any combination of
case.
        at
org.apache.xerces.framework.XMLParser.parse(XMLParser.java:878)
        at org.jdom.input.SAXBuilder.build(SAXBuilder.java:302)
        at org.jdom.input.SAXBuilder.build(SAXBuilder.java:373)
        at org.jdom.input.SAXBuilder.build(SAXBuilder.java:354)
        at ReceiveRequest.read(ReceiveRequest.java:104)
        at ReceiveRequest.main(ReceiveRequest.java:77)

Is anybody aware of a work around?
(FYI: I am still using the deprecated addChild(org.jdom.Element) and
getContent() methods )

I also have problems compiling. For the milestone builds (beta 3 and 4)
I got:
    [javac] C:\java\jdom\build\src\org\jdom\input\DOMBuilder.java:416:
             Method getPublicId() not found in interface
org.w3c.dom.DocumentType.
    [javac]                 String publicID = domDocType.getPublicId();
    [javac] C:\java\jdom\build\src\org\jdom\input\DOMBuilder.java:417:
            Method getSystemId() not found in interface
org.w3c.dom.DocumentType.
    [javac]                 String systemID = domDocType.getSystemId();

With the latest CSV build, I also get:
    [javac]
C:\java\jdom\build\src\org\jdom\output\DOMOutputter.java:263:
        Method createAttributeNS(java.lang.String, java.lang.String) not
found in interface or
g.w3c.dom.Document.
    [javac]              domAttr =
domDoc.createAttributeNS(attribute.getNamespaceURI(),

Has anybody else encountered this ?

thanks,

        Kjetil

--
Kjetil Larsen
mailto:kjetil@cs.stanford.edu
Tel: +31 (0)621 590666



From jhunter at collab.net  Mon Sep 11 14:30:00 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:04:55 2004
Subject: [jdom-interest] Validation using schemas, how?
References: <00bc01c01987$b79887c0$1501a8c0@travers> <39BBC4B2.ADC43ED7@nist.gov>
Message-ID: <39BD4ED8.E8A0A4F@collab.net>

> I also struggled with namespaces and I found that in SAXBuilder 
> the fact
> that the "namespaces" feature is hardwired to false prevents
> correct handling of schemas. Setting the property to true seemed to
> solve
> the problem.
> 
> This is an issue that I brought to the list but no one answered.
> Why is this property hardwired to false ? 

Because JDOM does its own namespace handling, which allows namespaces
and validation to work at the same time.

-jh-

From jhunter at collab.net  Mon Sep 11 14:35:01 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:04:55 2004
Subject: [jdom-interest] xml:lang and compilation problems
References: <39BC2117.E3668594@cs.stanford.edu>
Message-ID: <39BD5005.3006D6C0@collab.net>

> org.xml.sax.SAXException: The name "xml" is not legal for JDOM/XML
> Namespace pre
> fixs: Namespace prefixes cannot begin with "xml" in any combination of
> case.
>         at
> org.apache.xerces.framework.XMLParser.parse(XMLParser.java:878)
>         at org.jdom.input.SAXBuilder.build(SAXBuilder.java:302)
>         at org.jdom.input.SAXBuilder.build(SAXBuilder.java:373)
>         at org.jdom.input.SAXBuilder.build(SAXBuilder.java:354)
>         at ReceiveRequest.read(ReceiveRequest.java:104)
>         at ReceiveRequest.main(ReceiveRequest.java:77)
> 
> Is anybody aware of a work around?

I thought this was working, and someone else confirmed the latest code
worked.  I suggest you start up a debugger and see why the special case
logic for xml:lang isn't being invoked.  

> I also have problems compiling. 

>     [javac] C:\java\jdom\build\src\org\jdom\input\DOMBuilder.java:416:
>              Method getPublicId() not found in interface
> org.w3c.dom.DocumentType.
>     [javac]                 String publicID = domDocType.getPublicId();

You have an old DOM at the head of your classpath.  This has been
covered about 10 times before, scan the archives for that error msg for
details.  (It's in my queue to add it to the faq.)

-jh-

From jhunter at collab.net  Mon Sep 11 15:01:57 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:04:55 2004
Subject: [jdom-interest] Interesting MS whitespace discussion
Message-ID: <39BD5654.600F0407@collab.net>

Oh the fun of XML whitespace.  Here's what MS has to say on the topic.

http://msdn.microsoft.com/xml/xmlguide/Whitespace.asp

-jh-

From ctodd at alabanza.com  Mon Sep 11 18:05:40 2000
From: ctodd at alabanza.com (Chris Todd)
Date: Fri Aug  6 17:04:55 2004
Subject: [jdom-interest] is this an appropriate use of JDOM?
In-Reply-To: <39BD5654.600F0407@collab.net>
Message-ID: <NEBBIHEHKDMBPMCNJKNMGEMJDEAA.ctodd@alabanza.com>

Hello everyone-

I wanted to seek the opinions of JDOM users to make sure an idea I have
about how to use JDOM is not stupid.  ;-)  I hope you will forgive my
naivete, but I am a bit of a newbie to both Java and XML.

We are converting a Perl/PHP-based web application to Java (probably using
just servlets and perhaps JSP, but not using EJB).  This web app needs to
have a multi-lingual interface.  Our current implementation of this is
hideously inefficient and lingustically horrid, and I was hoping JDOM would
help.  ;-)

Here is the basic idea:

Our app only has about 50 or so 'pages', the text of which rarely ever
changes.  The text of these pages would be in XML documents, possibly one
document per page, with the translation for each language within appropriate
XML tags (e.g.
<english>
	<Greeting> Hello! </Greeting>
	...other document tags here...
</english>
<french>
	<Greeting> Bon Jour! </Greeting>
	...other document tags here...
</french>
etc.)

This XML document would be parsed into a JDOM object (probably one JDOM
object per language per page), and these objects would live in memory all
the time.  We would do that by instantiating one of these objects from each
servlet that serves up one 'page' of our app, and given the servlet life
cycle, both the servlet and the JDOM object would live in memory (please
feel free to correct me if I misunderstand the servlet life cycle; also, I
believe this is an example of the 'singleton' design pattern?).

When a servlet for a particular page gets called by a particular user, a
session variable (probably set by the login servlet) would indicate which
language to use, and the servlet would then obtain the appropriate JDOM
object and render it into HTML via XSLT (after doing other interesting work
like querying a database, etc.).

My questions are these:
1)  Am I just loopy, or does this make sense?
2)  Will I actually gain the performance advantages I think i can gain from
having my translations live in memory as JDOM objects?
3)  Do I understand the servlet life cycle correctly...can I actually have
my JDOM object live in memory for extended periods of time?

I know Java has resource bundles that are designed to handle I18N issues,
but from what I have seen, this would lead to translations on a
phrase-by-phrase basis, which we currently do, and have been roundly
criticized for it by our translators.  Our translators would much prefer
translating an entire document at a time, something that appears easy to do
with the XML document approach.

Finally, I know these sorts of issues are exactly what Cocoon was designed
for, but Cocoon really is major overkill for what we are doing.  I think (am
I wrong) that it would be fairly simple for us to create a home-grown
solution to our problem.

Thank you in advance for any comments or advice you provide, and for taking
time to help out a newbie.  ;-)

Sincerest regards,
Chris Todd


From jhunter at collab.net  Mon Sep 11 18:53:14 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:04:55 2004
Subject: [Fwd: [jdom-interest] Entity IDs]
Message-ID: <39BD8C8A.CEE56859@collab.net>

I'm digging through my inbox, and will be throwing out old threads that
were never finished.  Hopefully we can put some of these to rest. 
Here's the first.

-jh-
-------------- next part --------------
An embedded message was scrubbed...
From: Brett McLaughlin <brett.mclaughlin@lutris.com>
Subject: Re: [jdom-interest] Entity IDs
Date: Wed, 21 Jun 2000 13:24:31 -0500
Size: 4266
Url: http://jdom.org/pipermail/jdom-interest/attachments/20000911/0f6e2439/attachment.eml
From san at most5.krasnoyarsk.su  Mon Sep 11 20:07:31 2000
From: san at most5.krasnoyarsk.su (Vyacheslav Pedak)
Date: Fri Aug  6 17:04:55 2004
Subject: [jdom-interest] Problem with mixed content
Message-ID: <001801c01c66$9acdbbb0$232b09c3@san>

Hi,

I dowloaded JDom sources from 09.08.2000.
I have simple xml like this:
<?xml version="1.0" encoding="ISO-8859-1"?>
<test>
  <element>
    text
  </element>
</test>

and when I do 

        Document doc = builder.build(new File(filename));
        Element root = doc.getRootElement();
        System.out.println("hasMixedContent="+root.hasMixedContent());

I receive true, but there no mixed content in this xml.

I think the problem is in white space, because when I made xml like this:

<?xml version="1.0" encoding="ISO-8859-1"?>
<test><element>text</element></test>

all works fine.

Regards,
Vyacheslav Pedak.


From jhunter at collab.net  Tue Sep 12 00:03:14 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:04:55 2004
Subject: [jdom-interest] Problem with mixed content
References: <001801c01c66$9acdbbb0$232b09c3@san>
Message-ID: <39BDD532.13C0512F@collab.net>

> I dowloaded JDom sources from 09.08.2000.
> I have simple xml like this:
> <?xml version="1.0" encoding="ISO-8859-1"?>
> <test>
>   <element>
>     text
>   </element>
> </test>
> 
> and when I do
> 
>         Document doc = builder.build(new File(filename));
>         Element root = doc.getRootElement();
>         System.out.println("hasMixedContent="+root.hasMixedContent());
> 
> I receive true, but there no mixed content in this xml.

Sure there is.  There's lots of whitespace.  Yes, I agree that's kinda
stupid but that's XML for ya!  Without validation you can't tell if the
whitespace is ignorable or not.  Also notice that the getText() value
for the element is "\n    text\n  ".  Use getTextTrim() if you want just
"text".

-jh-

From brett.mclaughlin at lutris.com  Tue Sep 12 08:28:50 2000
From: brett.mclaughlin at lutris.com (Brett McLaughlin)
Date: Fri Aug  6 17:04:55 2004
Subject: [jdom-interest] Problem with mixed content
References: <001801c01c66$9acdbbb0$232b09c3@san>
Message-ID: <39BE4BB2.E0E87817@lutris.com>


Vyacheslav Pedak wrote:
> 
> Hi,
> 
> I dowloaded JDom sources from 09.08.2000.
> I have simple xml like this:
> <?xml version="1.0" encoding="ISO-8859-1"?>
> <test>
>   <element>
>     text
>   </element>
> </test>
> 
> and when I do
> 
>         Document doc = builder.build(new File(filename));
>         Element root = doc.getRootElement();
>         System.out.println("hasMixedContent="+root.hasMixedContent());
> 
> I receive true, but there no mixed content in this xml.

Yes it does. The root element has both character data (white space) and
elements. It would only have no mixed content if a DTD was present, and
specified that the element "test" could only have nested elements. JDOM
is doing exactly the right thing.

> 
> I think the problem is in white space, because when I made xml like this:
> 
> <?xml version="1.0" encoding="ISO-8859-1"?>
> <test><element>text</element></test>
> 
> all works fine.

As it should - there is no character data here.

This isn't a bug, this is adherence to the XML spec.

-Brett

> 
> Regards,
> Vyacheslav Pedak.
> 
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org

From jbernard at rochester.rr.com  Tue Sep 12 09:13:04 2000
From: jbernard at rochester.rr.com (Jehoiada Bernard)
Date: Fri Aug  6 17:04:56 2004
Subject: [jdom-interest] How to [easily] deal with optional children?
Message-ID: <002201c01cd4$55519bb0$0100a8c0@rochester.rr.com>

Hi,

Givent the following element declaration:
    <!ELEMENT Request (JobCreationRequest | JobModificationRequest | JobEstimationRequest | JobControlRequest | ServiceControlRequest)?>

A Request element can have one of the listed children. Is there a way to get the child element without attempting getChild("JobCreationRequest") then if that fails try getChild("JobModificationRequest") an so on.

What I really want to do is get the first (only) child of the Request element then use element.getName() to determine which one actually appears in the document.

Thanks

Jeddy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://jdom.org/pipermail/jdom-interest/attachments/20000912/422e3987/attachment.htm
From mikeb at cybersource.com  Tue Sep 12 10:09:38 2000
From: mikeb at cybersource.com (Blanton, Mike)
Date: Fri Aug  6 17:04:56 2004
Subject: [jdom-interest] Interesting problem
Message-ID: <31F57C58C456D411AA4D00B0D03D97CD1318B3@mtv-exch01.cybersource.com>

I've written a class that extends Document.  In that class, I have a
function called "createXMLFile", which basically takes a path, creates an
XML file from the extended document.  However, the main document has 2 root
nodes.
 
So, my code looks something like this:
 
public class ProductXMLDocument extends Document {
  public ProductXMLDocument() {
    super (new Element("root"));
    elemCatalog = new Element("catalog");
    this.setRootElement(elemCatalog);
  }
 
  public void createXMLFile(String _filePath) throws JDOMException,
IOException {
    FileOutputStream fos = new FileOutputStream(new File(_filePath,
"products.xml"));
    XMLOutputter xmlOut = new XMLOutputter();
    xmlOut.output(this, fos);
    fos.close(); // Is this necessary?
  }
}
 
When I look at the file, It adds the catalog node, then all of the products,
then another catalog node, then all of the products again.  Has anyone seen
this before?  I've tried taking the createXMLFile code out of the
ProductXMLDocument and put it in the code that calls it, but it yields the
same results.
 
Thanks.

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
Michael Blanton
Architect
CyberSource Professional Services
 <http://www.cybersource.com/> www.cybersource.com 
 <mailto:mikeb@cybersource.com> mikeb@cybersource.com
(408) 359-2232

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://jdom.org/pipermail/jdom-interest/attachments/20000912/330b5241/attachment.htm
From jhunter at collab.net  Mon Sep 11 19:42:28 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:04:56 2004
Subject: [Fwd: [jdom-interest] Entities with inner structure (proposed fix)]
Message-ID: <39BD9814.2D36327A@collab.net>

Entities thread...

-jh-
-------------- next part --------------
An embedded message was scrubbed...
From: Steve Weiss <sweiss@aamc.org>
Subject: Re: [jdom-interest] Entities with inner structure (proposed fix)
Date: Wed, 05 Jul 2000 12:02:12 -0400
Size: 4423
Url: http://jdom.org/pipermail/jdom-interest/attachments/20000911/12034d90/attachment.eml
From jhunter at collab.net  Mon Sep 11 19:39:31 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:04:56 2004
Subject: [Fwd: [jdom-interest] xmlns attributes]
Message-ID: <39BD9763.5B2F3280@collab.net>

Another old thread.

-jh-
-------------- next part --------------
An embedded message was scrubbed...
From: Kevin Regan <kevinr@valicert.com>
Subject: [jdom-interest] xmlns attributes
Date: Fri, 30 Jun 2000 17:58:08 -0700
Size: 7489
Url: http://jdom.org/pipermail/jdom-interest/attachments/20000911/45f4d0b7/attachment.eml
From mikeb at cybersource.com  Tue Sep 12 10:28:43 2000
From: mikeb at cybersource.com (Blanton, Mike)
Date: Fri Aug  6 17:04:56 2004
Subject: [jdom-interest] Adding attribute with a Prefix
Message-ID: <31F57C58C456D411AA4D00B0D03D97CD1318B6@mtv-exch01.cybersource.com>

I want to add an attribute to an element - "xml:lang" or "dt:dt".  There is
no namespace for the document.  Any ideas on how I can do this?

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
Michael Blanton
Architect
CyberSource Professional Services
 <http://www.cybersource.com/> www.cybersource.com 
 <mailto:mikeb@cybersource.com> mikeb@cybersource.com
(408) 359-2232

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://jdom.org/pipermail/jdom-interest/attachments/20000912/e5d36bbe/attachment.htm
From jhunter at collab.net  Tue Sep 12 11:42:45 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:04:56 2004
Subject: [jdom-interest] Relative URI namespaces
Message-ID: <39BE7925.20D97BE5@collab.net>

In the news....

Relative URI Namespace usage deprecated
http://xmlhack.com/read.php?item=758

  Dan Connolly announced a decision of the XML Plenary "to deprecate
  the use of relative URI references in namespace declarations."
  (Namespaces, W3C: 20:19 11 Sep 2000 UTC)


In light of this I propose we follow the Plenary's lead and add no
support for relative URI namespaces in JDOM.  (I'll assume happy
consensus unless I hear otherwise!)

-jh-

From jhunter at collab.net  Tue Sep 12 11:53:42 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:04:56 2004
Subject: [jdom-interest] How to [easily] deal with optional children?
References: <002201c01cd4$55519bb0$0100a8c0@rochester.rr.com>
Message-ID: <39BE7BB6.47AE212E@collab.net>

> What I really want to do is get the first (only) child of the Request
> element then use element.getName() to determine which one actually
> appears in the document.

getChildren() returns a List of children.

-jh-

From jhunter at collab.net  Tue Sep 12 12:12:34 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:04:56 2004
Subject: [jdom-interest] Interesting problem
References: <31F57C58C456D411AA4D00B0D03D97CD1318B3@mtv-exch01.cybersource.com>
Message-ID: <39BE8022.1C0EB87A@collab.net>

> I've written a class that extends Document.  In that class, I have a
> function called "createXMLFile", which basically takes a path, creates
> an XML file from the extended document.  However, the main document
> has 2 root nodes.

PLEASE EVERYONE WHO FILES A BUG REPORT: TEST AGAINST THE LATEST DAILY
CODE AND IN THE BUG REPORT *SAY* YOU'RE USING THE LATEST CODE.

I just added a new section to the README about this so hopefully I'll
need to say this less often.

-jh-

From Brad.Morgan at e-pubcorp.com  Tue Sep 12 14:07:35 2000
From: Brad.Morgan at e-pubcorp.com (Brad Morgan)
Date: Fri Aug  6 17:04:56 2004
Subject: [jdom-interest] Modified XMLOutputter which optionally omits white space
In-Reply-To: <NDBBLFGNKKGCBIJEAIJBKEOICGAA.Brad.Morgan@e-pubcorp.com>
Message-ID: <NDBBLFGNKKGCBIJEAIJBEEOOCGAA.Brad.Morgan@e-pubcorp.com>

I've been struggling with the fact that JDOM trees include or exclude
whitespace depending on the presence or absence of a DTD.

I think I understand this behavior but it doesn't make it any easier to deal
with.

Since XMLOutputter has options to add formatting to the output XML file, I
thought it should also have an option to remove (old) formatting as well.

This appears to solve my problem where I have modified the document and
possibly changed its structure as I added and removed elements.

I've attached my modified version below for consideration.  The original was
current on Friday but I didn't check to see if any changes were made over
the weekend.  From all the reading I've done about CVS, I think someone with
the proper access can properly merge my changes.

Brad Morgan
e-Publishing Corp.

Email: Brad.Morgan@e-pubcorp.com
Phone: (719)593-7377 x35
Fax: (719)593-2996

e-Publishing Corp. is a BroadVision company
NOTICE: This message is intended only for the use of the Addressee and may
contain information that is PRIVILEGED and CONFIDENTIAL. If you are not the
intended recipient, dissemination of this communication is prohibited. If
you have received this communication in error, please erase all copies of
the message and its attachments and notify us immediately.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: XMLOutputter.java
Type: application/octet-stream
Size: 33150 bytes
Desc: not available
Url : http://jdom.org/pipermail/jdom-interest/attachments/20000912/184d1acd/XMLOutputter.obj
From chris.laprun at nist.gov  Tue Sep 12 14:14:55 2000
From: chris.laprun at nist.gov (Christophe D. Laprun)
Date: Fri Aug  6 17:04:56 2004
Subject: [jdom-interest] Validation using schemas, how?
References: <00bc01c01987$b79887c0$1501a8c0@travers> <39BBC4B2.ADC43ED7@nist.gov> <39BD4ED8.E8A0A4F@collab.net>
Message-ID: <39BE9CCF.8BB5B13D@nist.gov>

Jason Hunter wrote:
> 
> > I also struggled with namespaces and I found that in SAXBuilder
> > the fact
> > that the "namespaces" feature is hardwired to false prevents
> > correct handling of schemas. Setting the property to true seemed to
> > solve
> > the problem.
> >
> > This is an issue that I brought to the list but no one answered.
> > Why is this property hardwired to false ?
> 
> Because JDOM does its own namespace handling, which allows namespaces
> and validation to work at the same time.

How come then that I had to change the "namespaces" feature to true to
be able to have my schemas validated and accepted by JDOM ? More
generally, what consequences does it have on the rest of JDOM ?

Regards,

Chris

-- 
Christophe Laprun    [Ingenieur ISIMA, France / Guest researcher @NIST]
web: http://www.nist.gov/speech/staff/laprunch.htm
email: chris.laprun@nist.gov
phone: (301) 975 3191             fax: (301) 670 0939
--
The universe seems neither benign nor hostile, merely indifferent -
Sagan

From EGalluzzo at synchrony.net  Tue Sep 12 15:08:01 2000
From: EGalluzzo at synchrony.net (Galluzzo, Eric)
Date: Fri Aug  6 17:04:56 2004
Subject: [jdom-interest] No namespaces for attributes without prefix
Message-ID: <51C6625F6F63D211853B0008C74C1A1EFA77CC@corp-exchg-001.synchrony.net>

When SAXBuilder (latest, from CVS) builds a document, it appears that the
attributes are created in the wrong namespace.  For example, in the
following (very small) document:

<foo:bar xmlns:foo="http://www.foo.com/" glurp="howdy"/>

the "glurp" attribute would be considered part of the default namespace,
whereas it should actually be part of the foo namespace.  The "foo:" prefix
is implied by the element itself being in the "foo" namespace.

I can easily supply a patch that fixes this, but I just want to make sure
that it is in fact broken before I do so -- since it used to work correctly,
a month or two ago (we just switched to the latest CVS version). :)

    - Eric

-- 
Eric Galluzzo   <><
Product Engineer
Synchrony Communications, Inc.

Work: http://www.synchrony.net/
Home: http://w3.one.net/~eng/


From EMorehouse at fool.com  Tue Sep 12 15:22:48 2000
From: EMorehouse at fool.com (Ed Morehouse)
Date: Fri Aug  6 17:04:56 2004
Subject: [jdom-interest] questions about org.jdom.ProcessingInstruction
References: <000201c01a33$238cd3e0$0a64a8c0@xpst450>
Message-ID: <39BEACB8.C536732E@fool.com>

I've been looking at org.jdom.ProcessingInstruction and have a few questions:

- The "data" portion of a ProcessingInstruction seems to be stored as both a
String and a Map; is this, in fact, the case?
- If so, what is the rationale for this, as opposed to just using one or the
other?
- Would a Map alone suffice to store all the possible "data payloads" a
processing instruction could legally have?
- If so, it seems to me that the Map would be more powerful (and more OO), and
would relieve the application programer from having to do a good deal of String
processing.  Does this seem right?  Am i missing something?
- There is a constructor that takes a Map and an internal Map already, but there
doesn't seem to be any way to get a Map back out from a ProcessingInstruction;
is this so?
- If yes, what would be the implications of adding a public Map getDataMap()
method to ProcessingInstruction?  If there weren't also a shadow data String,
manipulating the Map directly seems like it would be okay and wouldn't cause
corruption.  This seems like it would fit in with the philosophy of using Java's
native Collection interfaces to simplify XML programming, as in the case of the
live child List in Element.  Does this sound right?

I'd appreciate feedback and comments, especially from Jason and Brett, but also
from anyone with insight into this topic.

Thanks,

- Ed

                                  ------------
 
 - The happiest of people aren't the ones 
   who always have the best of everything;
   they are the ones who always make the best 
   of everything they have.

                                           Ed Morehouse
                                           Software Engineer/Evil Genius
                                           The Motley Fool

From scott at alodar.com  Tue Sep 12 15:29:59 2000
From: scott at alodar.com (Scott Ellsworth)
Date: Fri Aug  6 17:04:56 2004
Subject: [jdom-interest] Validation using schemas, how?
In-Reply-To: <39BE9CCF.8BB5B13D@nist.gov>
References: <00bc01c01987$b79887c0$1501a8c0@travers>
 <39BBC4B2.ADC43ED7@nist.gov>
 <39BD4ED8.E8A0A4F@collab.net>
Message-ID: <4.3.2.7.2.20000912152817.00afd990@iceweasel.com>

At 05:14 PM 9/12/2000 -0400, Christophe D. Laprun wrote:
>Jason Hunter wrote:
> > > I also struggled with namespaces and I found that in SAXBuilder
> > > the fact
> > > that the "namespaces" feature is hardwired to false prevents
> > > correct handling of schemas. Setting the property to true seemed to
> > > solve the problem.
> > >
> > > This is an issue that I brought to the list but no one answered.
> > > Why is this property hardwired to false ?
> >
> > Because JDOM does its own namespace handling, which allows namespaces
> > and validation to work at the same time.
>
>How come then that I had to change the "namespaces" feature to true to
>be able to have my schemas validated and accepted by JDOM ? More
>generally, what consequences does it have on the rest of JDOM ?

Travers Walker ran into the same thing - if he turns the namespace goodies 
back on for his xerces project, then validation takes place with his 
schema.  If it is off, as it is for default jdom, then xml schema are 
ignored in the validation process.

I have encouraged him to post the details to the list.

Scott
Scott Ellsworth
scott@alodar.com


From jhunter at collab.net  Tue Sep 12 15:39:38 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:04:56 2004
Subject: [jdom-interest] Modified XMLOutputter which optionally omits white 
 space
References: <NDBBLFGNKKGCBIJEAIJBEEOOCGAA.Brad.Morgan@e-pubcorp.com>
Message-ID: <39BEB0AA.24D0B8D5@collab.net>

> I've been struggling with the fact that JDOM trees include or exclude
> whitespace depending on the presence or absence of a DTD.

It's a fact of life when dealing with XML.  Whether you validate or not
changes the document you end up with.  I have lots of opinions on the
issue, but I don't have time to hop on a soapbox.

> Since XMLOutputter has options to add formatting to the output 
> XML file, I thought it should also have an option to remove 
> (old) formatting as well.

You mean you want a setOmitWhitespace() method apparently by looking at
your diff.  Something that prints the trimmed value instead of the raw
value.  Something like that should be part of a larger "how do we deal
with XMLOutputter now that we preserve whitespace" issue.  We still have
the problem that manually created elts or elts moved around are going to
have seriously inconsistent indentation compared to the original elts.

-jh-

From jhunter at collab.net  Tue Sep 12 15:47:26 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:04:56 2004
Subject: [jdom-interest] questions about org.jdom.ProcessingInstruction
References: <000201c01a33$238cd3e0$0a64a8c0@xpst450> <39BEACB8.C536732E@fool.com>
Message-ID: <39BEB27E.519D87EF@collab.net>

> - The "data" portion of a ProcessingInstruction seems to be stored as both a
> String and a Map; is this, in fact, the case?

Yep.

> - If so, what is the rationale for this, as opposed to just using one or the
> other?

Because technically it's a literal String with whitespace and all, but
people most often use it as a map.

> - Would a Map alone suffice to store all the possible "data payloads" a
> processing instruction could legally have?

Nope, you'd lose the option for literal formatting.  When you pass in a
Map you're explicitly not caring about formatting.

> - There is a constructor that takes a Map and an internal Map already, but there
> doesn't seem to be any way to get a Map back out from a ProcessingInstruction;
> is this so?

The getValue() provides access to the Map.

> - If yes, what would be the implications of adding a public Map getDataMap()
> method to ProcessingInstruction?  

It'd be annoying because to follow the JDOM style it'd have to be
mutable, and I'd rather not get into that.

> If there weren't also a shadow data String,

But there needs to be.

(Sorry for being terse, tons to do today.)

-jh-

From Brad.Morgan at e-pubcorp.com  Tue Sep 12 16:14:04 2000
From: Brad.Morgan at e-pubcorp.com (Brad Morgan)
Date: Fri Aug  6 17:04:56 2004
Subject: [jdom-interest] Modified XMLOutputter which optionally omits white  space
In-Reply-To: <39BEB0AA.24D0B8D5@collab.net>
Message-ID: <NDBBLFGNKKGCBIJEAIJBAEOPCGAA.Brad.Morgan@e-pubcorp.com>

> You mean you want a setOmitWhitespace() method apparently by looking at
> your diff.  Something that prints the trimmed value instead of the raw
> value.  Something like that should be part of a larger "how do we deal
> with XMLOutputter now that we preserve whitespace" issue.  We still have
> the problem that manually created elts or elts moved around are going to
> have seriously inconsistent indentation compared to the original elts.

I think my changes address the problem of manually created elts or elts
moved
having inconsistent indentation.  If I use my new constructor:

XMLOutputter("    ",true,true);

I have asked XMLOutputter to properly indent the output adding spacing and
newlines where it wants and also to remove the old, probably incorrect,
formatting (my new code).

In my limited testing it appears to do the right thing.

I'm happy with a larger, better solution, but this one appears to be small
and slightly better for now.

Regards,

Brad





From brett.mclaughlin at lutris.com  Tue Sep 12 16:20:16 2000
From: brett.mclaughlin at lutris.com (Brett McLaughlin)
Date: Fri Aug  6 17:04:56 2004
Subject: [jdom-interest] questions about org.jdom.ProcessingInstruction
References: <000201c01a33$238cd3e0$0a64a8c0@xpst450> <39BEACB8.C536732E@fool.com>
Message-ID: <39BEBA30.2539D6CE@lutris.com>


Ed Morehouse wrote:
> 
> I've been looking at org.jdom.ProcessingInstruction and have a few questions:
> 
> - The "data" portion of a ProcessingInstruction seems to be stored as both a
> String and a Map; is this, in fact, the case?

Yup.

> - If so, what is the rationale for this, as opposed to just using one or the
> other?

Honestly, I don't remember ;-) Most likely because in some cases, one
works /really/ well, and in others, the other does.

> - Would a Map alone suffice to store all the possible "data payloads" a
> processing instruction could legally have?

Not really. Remember that a PI does not have to be in attribute-value
format. This is perfectly legal:

<?target someValue?>

Here, there is no "key" for the map. But it would be fairly simple to
write the map in a way where some NO_NAME type key was set up, and the
value inserted. Of course, you could have multiple values with no name,
and you need different keys, but storage in a Map completely, (or in
String completely) is simple.

> - If so, it seems to me that the Map would be more powerful (and more OO), and
> would relieve the application programer from having to do a good deal of String
> processing.  Does this seem right?  Am i missing something?

Maybe just the odd PI case above.

> - There is a constructor that takes a Map and an internal Map already, but there
> doesn't seem to be any way to get a Map back out from a ProcessingInstruction;
> is this so?

It is so, because of the special case. It's one thing to store these
values internally with some sort of special NO_NAME key or whatever -
but giving that back to the developer I am against. That's why we let
them look up by attribute name, or get the whole thing raw, but not give
back the Map itself - if we store things completely in a Map, that Map
will sometimes have weird keys.

> - If yes, what would be the implications of adding a public Map getDataMap()
> method to ProcessingInstruction?  If there weren't also a shadow data String,
> manipulating the Map directly seems like it would be okay and wouldn't cause
> corruption.  This seems like it would fit in with the philosophy of using Java's
> native Collection interfaces to simplify XML programming, as in the case of the
> live child List in Element.  Does this sound right?

See above.

Hope this starts us down improving the PI class - it's been dormant for
a long time.

-Brett

> 
> I'd appreciate feedback and comments, especially from Jason and Brett, but also
> from anyone with insight into this topic.
> 
> Thanks,
> 
> - Ed
> 
>                                   ------------
> 
>  - The happiest of people aren't the ones
>    who always have the best of everything;
>    they are the ones who always make the best
>    of everything they have.
> 
>                                            Ed Morehouse
>                                            Software Engineer/Evil Genius
>                                            The Motley Fool
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org

From san at most5.krasnoyarsk.su  Tue Sep 12 23:02:47 2000
From: san at most5.krasnoyarsk.su (Vyacheslav Pedak)
Date: Fri Aug  6 17:04:56 2004
Subject: [jdom-interest] Problem with mixed content
References: <001801c01c66$9acdbbb0$232b09c3@san> <39BE4BB2.E0E87817@lutris.com>
Message-ID: <002c01c01d48$53cd2ce0$232b09c3@san>

Brett McLaughlin <brett.mclaughlin@lutris.com> wrote:

> > I have simple xml like this:
> > <?xml version="1.0" encoding="ISO-8859-1"?>
> > <test>
> >   <element>
> >     text
> >   </element>
> > </test>
> > 
> > and when I do
> > 
> >         Document doc = builder.build(new File(filename));
> >         Element root = doc.getRootElement();
> >         System.out.println("hasMixedContent="+root.hasMixedContent());
> > 
> > I receive true, but there no mixed content in this xml.
> 
> Yes it does. The root element has both character data (white space) and
> elements. It would only have no mixed content if a DTD was present, and
> specified that the element "test" could only have nested elements. JDOM
> is doing exactly the right thing.
> 

Thank you and Jason Hunter, now I understand my error.
But when I try to solve it, I found another one.
I rewrite my xml like this:

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE test [
  <!ELEMENT test (child) >
  <!ELEMENT child (#PCDATA| b)* >
  <!ELEMENT b (#PCDATA)>
]>
<test>
  <child>
    text <b>bold text</b> text
  </child>
</test>

So now root element did not have mixed content and child element has it.
But when I try this:
        Element root = doc.getRootElement();
        System.out.println("root.hasMixedContent="+root.hasMixedContent());
        Element elem = root.getChild("child");
        System.out.println("elem.hasMixedContent="+elem.hasMixedContent());

I received false in both cases.
What wrong again?

Vyacheslav Pedak



From san at most5.krasnoyarsk.su  Tue Sep 12 23:32:50 2000
From: san at most5.krasnoyarsk.su (Vyacheslav Pedak)
Date: Fri Aug  6 17:04:56 2004
Subject: [jdom-interest] Problem with mixed content
References: <001801c01c66$9acdbbb0$232b09c3@san> <39BE4BB2.E0E87817@lutris.com>
Message-ID: <003501c01d4c$7190aa00$232b09c3@san>

Hi,

In addition to previous letter, I test my code with another 
parser - com.icl.saxon.aelfred.SAXDriver.
With this parser all works fine, so I think, this is xerces problem.

Vyacheslav Pedak.



From traversw at innoforge.co.za  Wed Sep 13 04:37:29 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:56 2004
Subject: [jdom-interest] Getting schema validation working without enabling Xerces namespace support. How?
Message-ID: <00ae01c01d77$009d5ac0$1501a8c0@travers>

Hi everyone.

Lets finally settle this thread.

This is an extract from the September archives of the jdom-interest mailing
list.

>> I also struggled with namespaces and I found that in SAXBuilder
>> the fact
>> that the "namespaces" feature is hardwired to false prevents
>> correct handling of schemas. Setting the property to true seemed to
>> solve
>> the problem.
>>
>> This is an issue that I brought to the list but no one answered.
>> Why is this property hardwired to false ?

>Because JDOM does its own namespace handling, which allows namespaces
>and validation to work at the same time.

>-jh-

I might be wrong, but I get the impression that Jason's reply implies that
schema validation still works when Xerces namespace handling is disabled
because JDOM does its own namespace handling.  However, this is definitely
not my experience (the schema is ignored when Xerces namespace handling is
disabled) .  So, how does one get schema validation working without enabling
Xerces namespace handling?

In particular, how do I get the very simple example code in the email
attached below to work without first enabling Xerces namespace handling?


------------- Email sent to Scott Ellsworth on 12 September ---------------

Hi Scott.

I've got the Schemas working with JDOM.  The main problem was that JDOM
defaults to disabling namespace support in Xerces, which breaks schema
support.  You just have to go into the source file
jdom/src/java/org/jdom/input/SAXBuilder.java and edit the line that looks
like this:

  parser.setFeature("http://xml.org/sax/features/namespaces", false);

and change it to:

  parser.setFeature("http://xml.org/sax/features/namespaces", true);

Then rerun JDOM's Build script to get Ant to include your change into the
new jdom.jar, and copy the jdom.jar to wherever you keep your jar libraries.

After that, the following simple example works fine, throwing an exception
because validation by the schema fails.

File: test.xml
----------------------------------------------------------------------------
<?xml version="1.0" encoding="UTF-8"?>

<tag xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:noNamespaceSchemaLocation='test.xsd'>1</tag>
----------------------------------------------------------------------------


File: test.xsd
----------------------------------------------------------------------------
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/1999/XMLSchema">

<xsd:simpleType name="LimitedInt" base="xsd:integer">
  <xsd:minInclusive value="2"/>
</xsd:simpleType>

<xsd:element name="tag" type="LimitedInt"/>

</xsd:schema>
----------------------------------------------------------------------------


File: JdomTest.java
----------------------------------------------------------------------------
package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomTest {

  public static void main(String[] args) throws Exception {

    SAXBuilder builder = new SAXBuilder(true);
    Document doc = builder.build(new File("VagasConfig.xml

    Element currentElement = doc.getRootElement();
    String content = currentElement.getContent();

    System.out.println("The <tag> field contains: " + content);
  }
}
----------------------------------------------------------------------------






From elharo at metalab.unc.edu  Wed Sep 13 05:39:28 2000
From: elharo at metalab.unc.edu (Elliotte Rusty Harold)
Date: Fri Aug  6 17:04:56 2004
Subject: [jdom-interest] No namespaces for attributes without prefix
In-Reply-To: 
 <51C6625F6F63D211853B0008C74C1A1EFA77CC@corp-exchg-001.synchrony.net>
References: 
 <51C6625F6F63D211853B0008C74C1A1EFA77CC@corp-exchg-001.synchrony.net>
Message-ID: <p04330103b5e5257ccaf0@[168.100.203.234]>

At 6:08 PM -0400 9/12/00, Galluzzo, Eric wrote:
>When SAXBuilder (latest, from CVS) builds a document, it appears that the
>attributes are created in the wrong namespace.  For example, in the
>following (very small) document:
>
><foo:bar xmlns:foo="http://www.foo.com/" glurp="howdy"/>
>
>the "glurp" attribute would be considered part of the default namespace,
>whereas it should actually be part of the foo namespace.  The "foo:" prefix
>is implied by the element itself being in the "foo" namespace.
>

This is correct behavior. The glurp attribute is NOT in the 
http://www.foo.com/ namespace. Unrpefixed attributes are always in no 
namespace, not the default namespace, not the namespace of the 
element they belong to. This is the behavior specified and required 
by the Namespaces in XML specification. JDOM is simply inheriting 
this correct behavior from the underlying parser, which is what tells 
JDOM which namespace each attribute is (or is not) in.
-- 

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
|                  The XML Bible (IDG Books, 1999)                   |
|              http://metalab.unc.edu/xml/books/bible/               |
|   http://www.amazon.com/exec/obidos/ISBN=0764532367/cafeaulaitA/   |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://metalab.unc.edu/javafaq/ |
|  Read Cafe con Leche for XML News: http://metalab.unc.edu/xml/     |
+----------------------------------+---------------------------------+

From elharo at metalab.unc.edu  Wed Sep 13 06:03:15 2000
From: elharo at metalab.unc.edu (Elliotte Rusty Harold)
Date: Fri Aug  6 17:04:56 2004
Subject: [jdom-interest] Getting schema validation working without
 enabling Xerces namespace support. How?
In-Reply-To: <00ae01c01d77$009d5ac0$1501a8c0@travers>
References: <00ae01c01d77$009d5ac0$1501a8c0@travers>
Message-ID: <p04330106b5e52aa20084@[168.100.203.234]>

At 1:37 PM +0200 9/13/00, Travers Waker wrote:

>
>I might be wrong, but I get the impression that Jason's reply implies that
>schema validation still works when Xerces namespace handling is disabled
>because JDOM does its own namespace handling.  However, this is definitely
>not my experience (the schema is ignored when Xerces namespace handling is
>disabled) .  So, how does one get schema validation working without enabling
>Xerces namespace handling?
>

I'm not sure if I've quite got my head around this problem yet, so I 
may be misunderstanding just what the real issue is, but if I'm not, 
I think I can answer you.

Schemas require namespaces. This isn't a Xerces decision or a JDOM 
decision. It's simply the way the schema spec is written. If you're 
going to validate against a schema, your well-formedness checks must 
include the checks required by the Namespaces in XML specification, 
not just those required by XML 1.0. You cannot turn off namespace 
processing and still validate against a schema.
-- 

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
|                  The XML Bible (IDG Books, 1999)                   |
|              http://metalab.unc.edu/xml/books/bible/               |
|   http://www.amazon.com/exec/obidos/ISBN=0764532367/cafeaulaitA/   |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://metalab.unc.edu/javafaq/ |
|  Read Cafe con Leche for XML News: http://metalab.unc.edu/xml/     |
+----------------------------------+---------------------------------+

From elharo at metalab.unc.edu  Wed Sep 13 05:46:02 2000
From: elharo at metalab.unc.edu (Elliotte Rusty Harold)
Date: Fri Aug  6 17:04:56 2004
Subject: [jdom-interest] Adding attribute with a Prefix
In-Reply-To: 
 <31F57C58C456D411AA4D00B0D03D97CD1318B6@mtv-exch01.cybersource.com>
References: 
 <31F57C58C456D411AA4D00B0D03D97CD1318B6@mtv-exch01.cybersource.com>
Message-ID: <p04330104b5e527683e76@[168.100.203.234]>

At 10:28 AM -0700 9/12/00, Blanton, Mike wrote:
I want to add an attribute to an element - "xml:lang" or "dt:dt". 
There is no namespace for the document.  Any ideas on how I can do 
this?


This is a known issue. It should be fixed soon. Certainly before 1.0.
-- 

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
|                  The XML Bible (IDG Books, 1999)                   |
|              http://metalab.unc.edu/xml/books/bible/               |
|   http://www.amazon.com/exec/obidos/ISBN=0764532367/cafeaulaitA/   |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://metalab.unc.edu/javafaq/ |
|  Read Cafe con Leche for XML News: http://metalab.unc.edu/xml/     |
+----------------------------------+---------------------------------+

From EGalluzzo at synchrony.net  Wed Sep 13 07:50:56 2000
From: EGalluzzo at synchrony.net (Galluzzo, Eric)
Date: Fri Aug  6 17:04:56 2004
Subject: [jdom-interest] No namespaces for attributes without prefix
Message-ID: <51C6625F6F63D211853B0008C74C1A1EFA77CE@corp-exchg-001.synchrony.net>


> -----Original Message-----
> From: Elliotte Rusty Harold [mailto:elharo@metalab.unc.edu]
> Sent: Wednesday, September 13, 2000 8:39 AM
> To: Galluzzo, Eric; 'jdom-interest@jdom.org'
> Subject: Re: [jdom-interest] No namespaces for attributes 
> without prefix
> 
> 
> At 6:08 PM -0400 9/12/00, Galluzzo, Eric wrote:
> >When SAXBuilder (latest, from CVS) builds a document, it 
> appears that the
> >attributes are created in the wrong namespace.  For example, in the
> >following (very small) document:
> >
> ><foo:bar xmlns:foo="http://www.foo.com/" glurp="howdy"/>
> >
> >the "glurp" attribute would be considered part of the 
> default namespace,
> >whereas it should actually be part of the foo namespace.  
> The "foo:" prefix
> >is implied by the element itself being in the "foo" namespace.
> >
> 
> This is correct behavior. The glurp attribute is NOT in the 
> http://www.foo.com/ namespace. Unrpefixed attributes are always in no 
> namespace, not the default namespace, not the namespace of the 
> element they belong to. This is the behavior specified and required 
> by the Namespaces in XML specification.

Hmmm...I don't know about that.  I just re-read through the proposal, and
actually it didn't say anything about what namespace, if any, un-prefixed
attributes are in.  In Appendix A (which is non-normative), it says that
there's a per-element-type partition into which all un-prefixed attributes
fall.  So it looks like (in the above example) the attribute would be in the
"element bar within namespace http://www.foo.com/" namespace.  This is sort
of borne out by the <ExpAName .../> stuff in section A.3.  (By the way, when
I said "default namespace" in the original mail, I really meant "empty
namespace" -- sorry about that!)

In any case, it's a rather fuzzy area.  I guess I'm happy with them being
considered part of the empty namespace, if that's the consensus.

> JDOM is simply inheriting 
> this correct behavior from the underlying parser, which is what tells 
> JDOM which namespace each attribute is (or is not) in.

Actually, the parser is doing nothing more than giving you the qualified
name of the attribute (i.e. exactly what's in the XML file).  SAXBuilder
does the work of figuring out the prefix and doing its own namespace
processing.

    - Eric

From brett.mclaughlin at lutris.com  Wed Sep 13 08:41:47 2000
From: brett.mclaughlin at lutris.com (Brett McLaughlin)
Date: Fri Aug  6 17:04:56 2004
Subject: [jdom-interest] Problem with mixed content
References: <001801c01c66$9acdbbb0$232b09c3@san> <39BE4BB2.E0E87817@lutris.com> <002c01c01d48$53cd2ce0$232b09c3@san>
Message-ID: <39BFA03B.1C1526BB@lutris.com>


Vyacheslav Pedak wrote:
> 
> Brett McLaughlin <brett.mclaughlin@lutris.com> wrote:
> 
> > > I have simple xml like this:
> > > <?xml version="1.0" encoding="ISO-8859-1"?>
> > > <test>
> > >   <element>
> > >     text
> > >   </element>
> > > </test>
> > >
> > > and when I do
> > >
> > >         Document doc = builder.build(new File(filename));
> > >         Element root = doc.getRootElement();
> > >         System.out.println("hasMixedContent="+root.hasMixedContent());
> > >
> > > I receive true, but there no mixed content in this xml.
> >
> > Yes it does. The root element has both character data (white space) and
> > elements. It would only have no mixed content if a DTD was present, and
> > specified that the element "test" could only have nested elements. JDOM
> > is doing exactly the right thing.
> >
> 
> Thank you and Jason Hunter, now I understand my error.
> But when I try to solve it, I found another one.
> I rewrite my xml like this:
> 
> <?xml version="1.0" encoding="ISO-8859-1"?>
> <!DOCTYPE test [
>   <!ELEMENT test (child) >
>   <!ELEMENT child (#PCDATA| b)* >
>   <!ELEMENT b (#PCDATA)>
> ]>
> <test>
>   <child>
>     text <b>bold text</b> text
>   </child>
> </test>
> 
> So now root element did not have mixed content and child element has it.
> But when I try this:
>         Element root = doc.getRootElement();
>         System.out.println("root.hasMixedContent="+root.hasMixedContent());
>         Element elem = root.getChild("child");
>         System.out.println("elem.hasMixedContent="+elem.hasMixedContent());
> 
> I received false in both cases.
> What wrong again?

Now you did hit a bug ;-) We have some weird problems with inline DTDs
that I need to work on. So don't worry - this is not your fault ;-)

-Brett

> 
> Vyacheslav Pedak
> 
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org

From traversw at innoforge.co.za  Wed Sep 13 08:42:53 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:57 2004
Subject: [jdom-interest] Getting schema validation working without enabling Xerces namespace support. How?
References: <00ae01c01d77$009d5ac0$1501a8c0@travers> <p04330106b5e52aa20084@[168.100.203.234]>
Message-ID: <00f901c01d99$49680710$1501a8c0@travers>

> I'm not sure if I've quite got my head around this problem yet, so I
> may be misunderstanding just what the real issue is, but if I'm not,
> I think I can answer you.
>
> Schemas require namespaces. This isn't a Xerces decision or a JDOM
> decision. It's simply the way the schema spec is written. If you're
> going to validate against a schema, your well-formedness checks must
> include the checks required by the Namespaces in XML specification,
> not just those required by XML 1.0. You cannot turn off namespace
> processing and still validate against a schema.

OK, so schemas require namespaces.  This could either be in the form of
Xerces namespace support or JDOM's own namespace support.  One of these two
has to be enabled.

However, it is Xerces that is doing the validation with the schema, so
surely Xerces namespace support has to be enabled for schemas to work.  It
wouldn't help to enable namespace handling in JDOM because JDOM is not doing
the validation.

Fact:  The current build of JDOM does not validate against a schema when you
create a new SAXBuilder with validation set to true AND you stick the
relevant attributes pointing to the schema file onto the top of your .xml
document.  That info being:

<rootTag xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:noNamespaceSchemaLocation='schema.xsd'

But, when you change the source code of SAXBuilder to enable Xerces
namespace handling, suddenly schema validation works fine.

Jason says that Xerces namespace support is disabled by JDOM because JDOM
does its own namespace support.  Does this mean that JDOM no longer supports
validation by Schemas, even though the underlying Xerces parser does?

Thanks for the responses so far.

Travers



From brett.mclaughlin at lutris.com  Wed Sep 13 08:47:39 2000
From: brett.mclaughlin at lutris.com (Brett McLaughlin)
Date: Fri Aug  6 17:04:57 2004
Subject: [jdom-interest] Getting schema validation working without enabling 
 Xerces namespace support. How?
References: <00ae01c01d77$009d5ac0$1501a8c0@travers>
Message-ID: <39BFA19B.B4537BB8@lutris.com>


Travers Waker wrote:
> 
> Hi everyone.
> 
> Lets finally settle this thread.

OK. I can help ;-)

> 
> This is an extract from the September archives of the jdom-interest mailing
> list.
> 
> >> I also struggled with namespaces and I found that in SAXBuilder
> >> the fact
> >> that the "namespaces" feature is hardwired to false prevents
> >> correct handling of schemas. Setting the property to true seemed to
> >> solve
> >> the problem.
> >>
> >> This is an issue that I brought to the list but no one answered.
> >> Why is this property hardwired to false ?
> 
> >Because JDOM does its own namespace handling, which allows namespaces
> >and validation to work at the same time.
> 
> >-jh-
> 
> I might be wrong, but I get the impression that Jason's reply implies that
> schema validation still works when Xerces namespace handling is disabled
> because JDOM does its own namespace handling.  However, this is definitely
> not my experience (the schema is ignored when Xerces namespace handling is
> disabled) .  So, how does one get schema validation working without enabling
> Xerces namespace handling?

Well, not neccessarily. Xerces uses its internals to do XML Schema 
validation, and thus the line of communication is one way. In other
words, JDOM cannot process namespaces (in our way) and then relay that
information /back/ to Xerces. So Xerces needs the SAX namespaces
processing feature on. However, until now, JDOM turned that off, because
of a lot of details that are too long to type ;-) Seriously, it was
easier at the time to handle namespaces ourselves, extracting them from
the qName of an element. However, it appears that the time has come to
change this. Both because of XML Schema processing/validation, as well
as the need to capture multiple namespace declarations on an Element.

But this is a big deal - and it will take some refactoring of both
builders, and won't be quick. I'll try to get to it over the next few
days, but fair warning - I am /swamped/. Now for those of you wondering,
we will /not/ expose that feature for people to set off and on;
SAXBuilder relies on it being one way, and I'm not going to bog down all
that code with if/else statements in each callback to allow a user to
set it on or off. Besides, when I turn it on and make these changes, I
can think of no compelling reason for someone to want to turn it off.

So that's not a resolution, because the code isn't done, but I hope it's
an explanation and a satisfactory game plan.

Comments?

-Brett

> 
> In particular, how do I get the very simple example code in the email
> attached below to work without first enabling Xerces namespace handling?
> 
> ------------- Email sent to Scott Ellsworth on 12 September ---------------
> 
> Hi Scott.
> 
> I've got the Schemas working with JDOM.  The main problem was that JDOM
> defaults to disabling namespace support in Xerces, which breaks schema
> support.  You just have to go into the source file
> jdom/src/java/org/jdom/input/SAXBuilder.java and edit the line that looks
> like this:
> 
>   parser.setFeature("http://xml.org/sax/features/namespaces", false);
> 
> and change it to:
> 
>   parser.setFeature("http://xml.org/sax/features/namespaces", true);
> 
> Then rerun JDOM's Build script to get Ant to include your change into the
> new jdom.jar, and copy the jdom.jar to wherever you keep your jar libraries.
> 
> After that, the following simple example works fine, throwing an exception
> because validation by the schema fails.
> 
> File: test.xml
> ----------------------------------------------------------------------------
> <?xml version="1.0" encoding="UTF-8"?>
> 
> <tag xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
>     xsi:noNamespaceSchemaLocation='test.xsd'>1</tag>
> ----------------------------------------------------------------------------
> 
> File: test.xsd
> ----------------------------------------------------------------------------
> <?xml version="1.0" encoding="UTF-8"?>
> <xsd:schema xmlns:xsd="http://www.w3.org/1999/XMLSchema">
> 
> <xsd:simpleType name="LimitedInt" base="xsd:integer">
>   <xsd:minInclusive value="2"/>
> </xsd:simpleType>
> 
> <xsd:element name="tag" type="LimitedInt"/>
> 
> </xsd:schema>
> ----------------------------------------------------------------------------
> 
> File: JdomTest.java
> ----------------------------------------------------------------------------
> package tests.jdom;
> import java.io.File;
> import org.jdom.*;
> import org.jdom.input.*;
> 
> class JdomTest {
> 
>   public static void main(String[] args) throws Exception {
> 
>     SAXBuilder builder = new SAXBuilder(true);
>     Document doc = builder.build(new File("VagasConfig.xml
> 
>     Element currentElement = doc.getRootElement();
>     String content = currentElement.getContent();
> 
>     System.out.println("The <tag> field contains: " + content);
>   }
> }
> ----------------------------------------------------------------------------
> 
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org

From chris.laprun at nist.gov  Wed Sep 13 09:57:29 2000
From: chris.laprun at nist.gov (Christophe D. Laprun)
Date: Fri Aug  6 17:04:57 2004
Subject: [jdom-interest] Getting schema validation working without enabling 
 Xerces namespace support. How?
References: <00ae01c01d77$009d5ac0$1501a8c0@travers>
Message-ID: <39BFB1F9.D23F731@nist.gov>

Travers Waker wrote:
> 
> Hi everyone.
> 
> Lets finally settle this thread.

I agree. This is an issue that I brought up on August 24th and described
the fact that the problem came from the "namespaces" property. No one
reacted on the list. I am glad I am not alone with this problem. I don't
seem to have any problem with "namespaces" set to true but since it was
hardwired to false, I wanted to know why exactly and what are the
consequences of changing it to true.


> I might be wrong, but I get the impression that Jason's reply implies that
> schema validation still works when Xerces namespace handling is disabled
> because JDOM does its own namespace handling.  However, this is definitely
> not my experience (the schema is ignored when Xerces namespace handling is
> disabled) .  So, how does one get schema validation working without enabling
> Xerces namespace handling?

I asked Jason more details about his answer and he told me that I should
ask Brett about this (which what I did yesterday) since he (Jason)
doesn't use schemas.

Chris

-- 
Christophe Laprun    [Ingenieur ISIMA, France / Guest researcher @NIST]
web: http://www.nist.gov/speech/staff/laprunch.htm
email: chris.laprun@nist.gov
phone: (301) 975 3191             fax: (301) 670 0939
--
The universe seems neither benign nor hostile, merely indifferent -
Sagan

From chris.laprun at nist.gov  Wed Sep 13 10:00:57 2000
From: chris.laprun at nist.gov (Christophe D. Laprun)
Date: Fri Aug  6 17:04:57 2004
Subject: [jdom-interest] Getting schema validation working withoutenabling 
 Xerces namespace support. How?
References: <00ae01c01d77$009d5ac0$1501a8c0@travers> <p04330106b5e52aa20084@[168.100.203.234]>
Message-ID: <39BFB2C9.8155638B@nist.gov>

Elliotte Rusty Harold wrote:
> 
> At 1:37 PM +0200 9/13/00, Travers Waker wrote:
> 
> >
> >I might be wrong, but I get the impression that Jason's reply implies that
> >schema validation still works when Xerces namespace handling is disabled
> >because JDOM does its own namespace handling.  However, this is definitely
> >not my experience (the schema is ignored when Xerces namespace handling is
> >disabled) .  So, how does one get schema validation working without enabling
> >Xerces namespace handling?
> >
> 
> I'm not sure if I've quite got my head around this problem yet, so I
> may be misunderstanding just what the real issue is, but if I'm not,
> I think I can answer you.

I think that the real issue is that the "namespaces" property that
enables Xerces to handle Namespaces is hardwired to false in SAXBuilder
thus preventing correct handling of Schemas in JDOM. The question is
(from my point of view at least): why is it hardwired to false ? Why
isn't there any possibility to programmatically set this in JDOM ? What
are the consequences on the whole API to set this to true ?

Chris

-- 
Christophe Laprun    [Ingenieur ISIMA, France / Guest researcher @NIST]
web: http://www.nist.gov/speech/staff/laprunch.htm
email: chris.laprun@nist.gov
phone: (301) 975 3191             fax: (301) 670 0939
--
The universe seems neither benign nor hostile, merely indifferent -
Sagan

From pvg at c-c-s.com  Wed Sep 13 10:02:54 2000
From: pvg at c-c-s.com (Peter V. Gadjokov)
Date: Fri Aug  6 17:04:57 2004
Subject: [jdom-interest] Getting schema validation working without ena
	bling  Xerces namespace support. How?
Message-ID: <704ECFDA88B3D311B5F000A0C959E5B601FBCD@adobo.c2labs.com>

Brett McLaughlin wrote:


>So that's not a resolution, because the code isn't done, but I hope 
>it's an explanation and a satisfactory game plan.
>Comments?

I'm in the same boat as the others who've brought this up with
regards to schema validation, so I'd rather see JDOM use the 
facilities of the underlying parser (always, with no other option
is fine, if not even better, no chance of confusion). So this is my
two bit +1.

-pvg

From pvg at c-c-s.com  Wed Sep 13 10:16:49 2000
From: pvg at c-c-s.com (Peter V. Gadjokov)
Date: Fri Aug  6 17:04:57 2004
Subject: [jdom-interest] No namespaces for attributes without prefix
Message-ID: <704ECFDA88B3D311B5F000A0C959E5B601FBCE@adobo.c2labs.com>

>Hmmm...I don't know about that.  I just re-read through the 
>proposal, and actually it didn't say anything about what 
>namespace, if any, un-prefixed attributes are in.  
>In Appendix A (which is non-normative), it says that
>there's a per-element-type partition into which all un-prefixed >> 
>attributes fall.  

The normative section definitely says that default namespaces do not
apply to attributes. Whether that means they are in the empty
namespace may not be explicitly stated but it is explicitly stated
they are not in the elements declared or defaulted namespace. 
JDOM's behaviour is in line with any other namespace-capable 
parser, when the change is made so that SAXBuilder no longer does
it's own namespace processing, the behaviour will be exactly what 
you see now. While I don't know how airtight this interpretation of 
the spec is - it is though, as you suspect, 'the consensus'.

-pvg

From jhunter at collab.net  Wed Sep 13 11:39:01 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:04:57 2004
Subject: [jdom-interest] Getting schema validation working without enabling 
 Xerces namespace support. How?
References: <00ae01c01d77$009d5ac0$1501a8c0@travers> <39BFA19B.B4537BB8@lutris.com>
Message-ID: <39BFC9C5.F6CEC80A@collab.net>

> Seriously, it was
> easier at the time to handle namespaces ourselves, extracting 
> them from the qName of an element.
> However, it appears that the time has come to
> change this. Both because of XML Schema processing/validation, as well
> as the need to capture multiple namespace declarations on an Element.

Before this refactoring, why don't you list (for the record and to make
sure we have consensus the refactoring is right) what we *lose* by
turning on namespaces in the parser.  For example, how does this affect
DTD-based validation for docs with namespaces?

-jh-

From jhunter at collab.net  Wed Sep 13 11:59:24 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:04:57 2004
Subject: [jdom-interest] serialVersionUID
References: <00090807593600.20305@jeremiah> <39B986A0.C155EEFD@collab.net> <00091310235302.25332@jeremiah>
Message-ID: <39BFCE8C.2CAC5D15@collab.net>

> I think it is completely safe to stamp the above classes 
> ( except namespace of course) with a SVID.

OK, but let's be clear on the benefit we gain.  Per
http://java.sun.com/j2se/1.3/docs/guide/serialization/spec/version.doc.html
it seems the SUID is a hash of the class name, fields, and methods.  So
if the methods are subject to change but not the variables then it's a
good idea to fix the SUID so serialization can occur between different
versions of the class that hold the same variable data.

Now, what happens when we add or remove a variable?  From 
http://java.sun.com/j2se/1.3/docs/guide/serialization/spec/version.doc7.html
it looks like an added field will have its value set to the default on
deserialization of an old version, which will probably break the class. 
So at that point we'd have to manually regen the SUID.  A deleted field
(less likely in JDOM) would be ignored on deserialization of an old
version and that's just fine.

So is the proposal to assign the SUID now for beta5 with a note to
update it should we ever add a variable or perform any other action
listed at
http://java.sun.com/j2se/1.3/docs/guide/serialization/spec/version.doc7.html?

-jh-

From wtekeu at otcfin.com  Wed Sep 13 13:03:07 2000
From: wtekeu at otcfin.com (Wally FRAND)
Date: Fri Aug  6 17:04:57 2004
Subject: [jdom-interest] Error launching SAXBuilder
Message-ID: <004a01c01dbd$b6cbae00$930a1eac@witangroup.com>

I can't understand the following error :

Error launching SAXBuilder: The entity "eacute" was referenced, but not declared.: Error on line 24 of XML document: The entity "nbsp" was referenced, but not declared.

Did someone already encounter this error message ? Actually, I don't know how to declare an entity within SAX.

Thanks.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://jdom.org/pipermail/jdom-interest/attachments/20000913/c4469533/attachment.htm
From elharo at metalab.unc.edu  Wed Sep 13 13:33:44 2000
From: elharo at metalab.unc.edu (Elliotte Rusty Harold)
Date: Fri Aug  6 17:04:57 2004
Subject: [jdom-interest] Namespace declarations
In-Reply-To: <3951085F.36695160@lutris.com>
References: <3951281E.6EFD076D@metalab.unc.edu>
 <3951085F.36695160@lutris.com>
Message-ID: <p04330103b5e5924a5b09@[168.100.203.234]>

I've been thinking about how to handle namespace declarations that 
don't map to any actual element or attribute in the document. These 
would customarily be prefixes used in attribute values or 
theoretically in element content.  I've only been able to develop two 
solutions to this problem, nether of which I like. Before I start 
writing code, I wanted to toss this out for further discussion.

Solution 1:

   Each element keeps track of namespace declarations (i.e. xmlns 
attributes) as well the namespace it actually uses. The builders 
would have to produce these form the input documents (not too hard) 
and we'd need to add an API for attaching new ones to elements. The 
XMLOutputter would need to change as well. We could still (and I'd 
argue should still) not require people to add namespace declarations 
to elements just to declare prefixes actually used on elements and 
attributes. Instead the XMLOutputter could deduce these. It would, 
however, check to make sure that it wasn't duplicating an existing 
xmlns declaration.

Thorniest issue with this approach: How do we handle conflicts 
between xmlns attributes and the prefixes actually used? More error 
checking and exception throwing is needed to prevent the possibility 
of using the same prefix or default namespace to refer to more than 
one URI within a single start tag. In fact we actually need this now, 
because it's possible for attributes and elements to define the same 
prefix in multiple ways within a start tag.

Solution 2:

   We allow attribute values to have a namespace URI attached to them. 
This would be optional. Most people wouldn't need to use this. The 
builders would still need to change to look for things that appeared 
to be prefixes in attribute values.  There's still a possibility of 
conflict between different prefixed names with the same prefix in a 
single start tag. Also I'm not sure it's at all intuitive.  Question: 
would there ever be more than one namespace prefix in a single 
attribute value?


I'd still like to come up with a solution that's cleaner than either 
of these. If anyone has any ideas I'd love to hear them.
-- 

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
|                  The XML Bible (IDG Books, 1999)                   |
|              http://metalab.unc.edu/xml/books/bible/               |
|   http://www.amazon.com/exec/obidos/ISBN=0764532367/cafeaulaitA/   |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://metalab.unc.edu/javafaq/ |
|  Read Cafe con Leche for XML News: http://metalab.unc.edu/xml/     |
+----------------------------------+---------------------------------+

From dan.Rubin at qwest.com  Wed Sep 13 16:11:58 2000
From: dan.Rubin at qwest.com (Rubin, Dan)
Date: Fri Aug  6 17:04:57 2004
Subject: [jdom-interest] XMLOutputter and InputSource ??
Message-ID: <597F8A30943CD21185CC00104BC6BCF60CC28BAD@DUNTX005>

Hello,

I downloaded jdom to help manipulate XML in an servlet based application
that is currently using saxon (http://users.iclway.co.uk/mhkay/saxon/) to
transform XSL/XML into HTML.  Basically I want to use jdom to create the XML
document and then use that XML to execute the transform() method on a saxon
StyleSheetInstance object.  That is where I am stuck.  I have
StyleSheetInstance.transform(InputSource source) and
XMLOutputter.output(Document doc, java.io.OutputStream out).  I can create
an InputSource object from an InputStream object, but the jdom
XMLOutputter.output() method dumps to a OutputStream object?  I am confused!
How do you do this?  What am I missing?  Anyone?

FYI.  I got the current version of jdom (beta 4) to run under JDK1.1.  It
was really easy to do using the Sun collections package and doing some very
minor code modifications to jdom (added imports for the packages in the
JDK1.1 collections.jar, replaced File.toURL(), Double.parseDouble(value) and
Float.parseFloat(value) with JDK1.1 compatible code)...  That's it... Just
in case someone else needed to use jdom under 1.1.

- Dan

From pvg at c-c-s.com  Wed Sep 13 16:33:47 2000
From: pvg at c-c-s.com (Peter V. Gadjokov)
Date: Fri Aug  6 17:04:57 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <704ECFDA88B3D311B5F000A0C959E5B601FBD4@adobo.c2labs.com>

Actually the point of setting the serialVersionUID is to say 'do not compute
one for me' to the serialization mechanism. One is computed automagically
for all classes that do not explicitly set one so if you wanted it to change
when non-compatible changes are made, you might as well leave things as they
are. Setting it explicitly in the class is an indication that the class will
deal with changes on its own (since the normal serialVersionUID computation
is quite draconian - adding a new public method or changing an existing
method to final would break serialization by producing a new
serialVersionUID). If JDOM classes wanted to support stable long
term-serialization in a solid way, several changes need to be made, in
particular, classes should handle their serialization explicitly and
generally avoid shortcuts like 'defaultWriteObject'. Transient members
should still be used for documentation purposes. An implementation would
look something like this - 

public class Element implements Serializable, ...
{
    private static final long serialVersionUID = -342323242344L;

    private static final JDOM_ELEM_SERIALVER = 1;

    // Serialized fields
    protected String name;
    protected List attributes;
    protected List content;

    protected transient Namespace namespace;
    protected transient Element   parent;
    protected transient boolean   isRootElement;
    private   transient String    textualContent;
    private   transient String    trimmedContent;
 
  [...]

private void writeObject(ObjectOutputStream out) throws IOException
{
    out.writeInt(JDOM_ELEM_SERIALVER);
    out.writeString(name);
    out.writeObject(attributes);
    out.writeObject(content);
    out.writeObject(namespace.getPrefix());
    out.writeObject(namespace.getURI());
}

private Object readObject(ObjectInputStream in) throws IOException,...
{
    int mySerialVer = in.readInt();
    if (mySerialVer == JDOM_ELEM_SERIALVER)
    {
        // read name, attributes, content
        // loop over child elements, set parent on all children
    }
    else if (//deal with older arch ....
    {
       [...]
    }
    else
       throw new StreamCorruptedException();
}


Now, that's obviously more work to put in and maintain than relying on
default serialization - but I think just about all of this is required to
achieve managable long-term persistence. the JDOM_ELEM_SERIALVER is an
additional constant the class uses to distinguish between different,
backward compatible serialization versions - this is not something
serialVersionUID supports, there are only two options there - the versions
matches and you read or it doesnt and you fail; in order to get backward
compatability for old archives, one has to maintain explicit externalization
methods. Note that parents are not serialized and neither is isRootElement
(something that should be tracked and set by Documents serialization
methods). 

If we want to go that route, I can whip these it out fairly quickly and
submit a patch.


-pvg

-----Original Message-----
From: Jason Hunter [mailto:jhunter@collab.net]
Sent: Wednesday, September 13, 2000 11:59 AM
To: Jeremiah Jahn
Cc: jdom interest
Subject: Re: [jdom-interest] serialVersionUID


> I think it is completely safe to stamp the above classes 
> ( except namespace of course) with a SVID.

OK, but let's be clear on the benefit we gain.  Per
http://java.sun.com/j2se/1.3/docs/guide/serialization/spec/version.doc.html
it seems the SUID is a hash of the class name, fields, and methods.  So
if the methods are subject to change but not the variables then it's a
good idea to fix the SUID so serialization can occur between different
versions of the class that hold the same variable data.

Now, what happens when we add or remove a variable?  From 
http://java.sun.com/j2se/1.3/docs/guide/serialization/spec/version.doc7.html
it looks like an added field will have its value set to the default on
deserialization of an old version, which will probably break the class. 
So at that point we'd have to manually regen the SUID.  A deleted field
(less likely in JDOM) would be ignored on deserialization of an old
version and that's just fine.

So is the proposal to assign the SUID now for beta5 with a note to
update it should we ever add a variable or perform any other action
listed at
http://java.sun.com/j2se/1.3/docs/guide/serialization/spec/version.doc7.html
?

-jh-
_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com

From ndjc at continuus.com  Wed Sep 13 17:35:12 2000
From: ndjc at continuus.com (Nick Crossley)
Date: Fri Aug  6 17:04:57 2004
Subject: [jdom-interest] XMLOutputter and empty elements
Message-ID: <000701c01de3$a5819ad0$070aa8c0@continuus.com>

For various reasons (post processing by other tools that are not proper XML
parsers),
I need to have empty elements in my XML shown as <TAG></TAG> and not as
<TAG/>.

I am doing this by extending from XMLOutputter, and redefining printElement.
However, with the current structure of printElement, I have to repeat a lot
of code
I really do not want to know about, in the handling of name spaces.

It would be convenient if there was an option not to abbreviate empty
elements,
or if printElement was restructured to make subclassing more convenient.

Nick Crossley.
ndjc@continuus.com


From pvg at c-c-s.com  Wed Sep 13 17:31:32 2000
From: pvg at c-c-s.com (Peter V. Gadjokov)
Date: Fri Aug  6 17:04:57 2004
Subject: [jdom-interest] Namespace declarations
Message-ID: <704ECFDA88B3D311B5F000A0C959E5B601FBD5@adobo.c2labs.com>

Could you describe what the two kinds of namespace declaration look like? It
sounds like (or I'm misunderstanding) there is some other way to declare a
namespace beyond: 

<somelement xmlns:foo="someURI" /> ?

Thanks,

-pvg


-----Original Message-----
From: Elliotte Rusty Harold [mailto:elharo@metalab.unc.edu]
Sent: Wednesday, September 13, 2000 1:34 PM
To: jdom-interest@jdom.org
Subject: [jdom-interest] Namespace declarations


I've been thinking about how to handle namespace declarations that 
don't map to any actual element or attribute in the document. These 
would customarily be prefixes used in attribute values or 
theoretically in element content.  I've only been able to develop two 
solutions to this problem, nether of which I like. Before I start 
writing code, I wanted to toss this out for further discussion.

Solution 1:

   Each element keeps track of namespace declarations (i.e. xmlns 
attributes) as well the namespace it actually uses. The builders 
would have to produce these form the input documents (not too hard) 
and we'd need to add an API for attaching new ones to elements. The 
XMLOutputter would need to change as well. We could still (and I'd 
argue should still) not require people to add namespace declarations 
to elements just to declare prefixes actually used on elements and 
attributes. Instead the XMLOutputter could deduce these. It would, 
however, check to make sure that it wasn't duplicating an existing 
xmlns declaration.

Thorniest issue with this approach: How do we handle conflicts 
between xmlns attributes and the prefixes actually used? More error 
checking and exception throwing is needed to prevent the possibility 
of using the same prefix or default namespace to refer to more than 
one URI within a single start tag. In fact we actually need this now, 
because it's possible for attributes and elements to define the same 
prefix in multiple ways within a start tag.

Solution 2:

   We allow attribute values to have a namespace URI attached to them. 
This would be optional. Most people wouldn't need to use this. The 
builders would still need to change to look for things that appeared 
to be prefixes in attribute values.  There's still a possibility of 
conflict between different prefixed names with the same prefix in a 
single start tag. Also I'm not sure it's at all intuitive.  Question: 
would there ever be more than one namespace prefix in a single 
attribute value?


I'd still like to come up with a solution that's cleaner than either 
of these. If anyone has any ideas I'd love to hear them.
-- 

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
|                  The XML Bible (IDG Books, 1999)                   |
|              http://metalab.unc.edu/xml/books/bible/               |
|   http://www.amazon.com/exec/obidos/ISBN=0764532367/cafeaulaitA/   |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://metalab.unc.edu/javafaq/ |
|  Read Cafe con Leche for XML News: http://metalab.unc.edu/xml/     |
+----------------------------------+---------------------------------+
_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com

From bob at accurev.com  Wed Sep 13 17:58:28 2000
From: bob at accurev.com (bob)
Date: Fri Aug  6 17:04:57 2004
Subject: [jdom-interest] Namespace declarations
In-Reply-To: <p04330103b5e5924a5b09@[168.100.203.234]>
Message-ID: <Pine.LNX.3.96.1000913205329.12780O-100000@exeter.exeter.org>

> Question: 
> would there ever be more than one namespace prefix in a single 
> attribute value?

Most decidedly YES.  XSLT uses XPath which could certainly
describe a path containing many different prefixes.

<sample myXpath="nsOne:a/nsTwo:b/@nsThree:b"/>

I don't think JDOM should go looking in attribute values, because
we simple don't know how prefixes will always be used within them.

My XPath impl internally just needs *something* to query,
and ask "what is the URI mapped to nsOne?".  


	-bob


From brett.mclaughlin at lutris.com  Wed Sep 13 19:57:30 2000
From: brett.mclaughlin at lutris.com (Brett McLaughlin)
Date: Fri Aug  6 17:04:57 2004
Subject: [jdom-interest] XMLOutputter and empty elements
References: <000701c01de3$a5819ad0$070aa8c0@continuus.com>
Message-ID: <39C03E9A.F9751247@lutris.com>

Wow. This was such a good and simple suggestion that I put it into CVS
right now. Get the latest version, Nick, and do this:

XMLOutputter outputter = new XMLOutputter();
outputter.setExpandEmptyElements(true);
outputter.output(myDoc);

Now aren't I a nice guy ;-)

Thanks,
Brett

Nick Crossley wrote:
> 
> For various reasons (post processing by other tools that are not proper XML
> parsers),
> I need to have empty elements in my XML shown as <TAG></TAG> and not as
> <TAG/>.
> 
> I am doing this by extending from XMLOutputter, and redefining printElement.
> However, with the current structure of printElement, I have to repeat a lot
> of code
> I really do not want to know about, in the handling of name spaces.
> 
> It would be convenient if there was an option not to abbreviate empty
> elements,
> or if printElement was restructured to make subclassing more convenient.
> 
> Nick Crossley.
> ndjc@continuus.com
> 
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org

From guru at edamame.stinky.com  Wed Sep 13 19:23:43 2000
From: guru at edamame.stinky.com (Alex Chaffee)
Date: Fri Aug  6 17:04:57 2004
Subject: [jdom-interest] fixing line endings
Message-ID: <20000913192343.C18335@edamame.stinky.com>

The following patch should fix things so .bat files and .sh files get
the "right" line endings no matter which platform the jar is built on. 

-- 
Alex Chaffee                       mailto:alex@jguru.com
jGuru - Java News and FAQs         http://www.jguru.com/alex/
Creator of Gamelan                 http://www.gamelan.com/
Founder of Purple Technology       http://www.purpletech.com/
Curator of Stinky Art Collective   http://www.stinky.com/



Index: build.xml
===================================================================
RCS file: /home/cvspublic/jdom/build.xml,v
retrieving revision 1.12
diff -u -r1.12 build.xml
--- build.xml	2000/09/06 22:20:24	1.12
+++ build.xml	2000/09/14 09:32:09
@@ -158,6 +158,8 @@
   <!-- Creates the class package                                           -->
   <!-- =================================================================== -->
   <target name="package" depends="compile">
+    <fixcrlf srcdir="." includes="*.bat" cr="add"/>
+    <fixcrlf srcdir="." includes="*.sh" cr="remove"/>
     <jar jarfile="${build.dir}/${name}.jar"
          basedir="${build.dest}"
          includes="org/**"/>

From jhunter at collab.net  Thu Sep 14 02:33:07 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:04:57 2004
Subject: [jdom-interest] serialVersionUID
References: <704ECFDA88B3D311B5F000A0C959E5B601FBD4@adobo.c2labs.com>
Message-ID: <39C09B53.F849E6BD@collab.net>

Great post, Peter!

> if you wanted it to change
> when non-compatible changes are made, you might as well leave 
> things as they are. Setting it explicitly in the class is an 
> indication that the class will
> deal with changes on its own 

Well, there's one important benefit to the simple model.  If our
internal data structures don't change but our public interfaces do
(because we add new setters and such), then by assigning an sVUID we
gain what could be called "short-term compatibility", that is
compatibility until the variables change.

> If JDOM classes wanted to support stable long
> term-serialization in a solid way, several changes need to be made, in
> particular, classes should handle their serialization explicitly and
> generally avoid shortcuts like 'defaultWriteObject'. 

Sounds like a potentially useful feature, with no real downside other
than a little extra coding work and maintenance.  What do people think?  
Is serialization important as long-term storage?  Or should we just tell
people to use *XML* as long term storage (a very reasonable
alternative)?

BTW, do any DOM impls support long-term serialization, or would this be
another JDOM extra?

-jh-

From jhunter at collab.net  Thu Sep 14 02:43:03 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:04:57 2004
Subject: [jdom-interest] Re: fixing line endings
References: <20000913192343.C18335@edamame.stinky.com>
Message-ID: <39C09DA7.94675AF@collab.net>

Added the patch.  I presume the fixcrlf behavior is recursive?

-jh-

Alex Chaffee wrote:
> 
> The following patch should fix things so .bat files and .sh files get
> the "right" line endings no matter which platform the jar is built on.
> 
> --
> Alex Chaffee                       mailto:alex@jguru.com
> jGuru - Java News and FAQs         http://www.jguru.com/alex/
> Creator of Gamelan                 http://www.gamelan.com/
> Founder of Purple Technology       http://www.purpletech.com/
> Curator of Stinky Art Collective   http://www.stinky.com/
> 
> Index: build.xml
> ===================================================================
> RCS file: /home/cvspublic/jdom/build.xml,v
> retrieving revision 1.12
> diff -u -r1.12 build.xml
> --- build.xml   2000/09/06 22:20:24     1.12
> +++ build.xml   2000/09/14 09:32:09
> @@ -158,6 +158,8 @@
>    <!-- Creates the class package                                           -->
>    <!-- =================================================================== -->
>    <target name="package" depends="compile">
> +    <fixcrlf srcdir="." includes="*.bat" cr="add"/>
> +    <fixcrlf srcdir="." includes="*.sh" cr="remove"/>
>      <jar jarfile="${build.dir}/${name}.jar"
>           basedir="${build.dest}"
>           includes="org/**"/>

From guru at edamame.stinky.com  Wed Sep 13 22:08:40 2000
From: guru at edamame.stinky.com (Alex Chaffee)
Date: Fri Aug  6 17:04:57 2004
Subject: [jdom-interest] Re: fixing line endings
In-Reply-To: <39C09DA7.94675AF@collab.net>; from jhunter@collab.net on Thu, Sep 14, 2000 at 02:43:03AM -0700
References: <20000913192343.C18335@edamame.stinky.com> <39C09DA7.94675AF@collab.net>
Message-ID: <20000913220840.D18335@edamame.stinky.com>

You mean, it adds an infinite number of CRs?

Really, I don't know what you mean by 'recursive.'  It doesn't search
all subdirectories, if that's what you mean (change the pattern to
"**/*.bat" for that).

Also, the same lines should be added to the jdom-contrib build.xml

 - A

On Thu, Sep 14, 2000 at 02:43:03AM -0700, Jason Hunter wrote:
> Added the patch.  I presume the fixcrlf behavior is recursive?
> 
> -jh-
> 

-- 
Alex Chaffee                       mailto:alex@jguru.com
jGuru - Java News and FAQs         http://www.jguru.com/alex/
Creator of Gamelan                 http://www.gamelan.com/
Founder of Purple Technology       http://www.purpletech.com/
Curator of Stinky Art Collective   http://www.stinky.com/

From brett.mclaughlin at lutris.com  Thu Sep 14 08:55:30 2000
From: brett.mclaughlin at lutris.com (Brett McLaughlin)
Date: Fri Aug  6 17:04:57 2004
Subject: [jdom-interest] Mailing List for JDOM
Message-ID: <39C0F4F2.BC17B242@lutris.com>

The list is fixed... sorry I forgot to get back to you on that.

Hey, isn't your bug in getAttribute().getValue():

>>>>>>>
I have simple XML file with elements like this:

<resource key="REGEX" value="m/[a-z].*\\W+/s" />


when I read it in and call Element.getAttributeValue("value"), I get
this  
as the string:
m/[a-z].*\W+/s

where the original has an escaped "\\" in it:
m/[a-z].*\\W+/s

Any idea what gives?
<<<<<<<

Isn't this simply a case of Java doing the right thing? The backslash
("\") is an escape character, which means that anytime it goes into a
String, it essentially gets turned into an escape sequence. So "\\" is a
way to output "\" in a program. I think if you want "\\" in your output,
you /should/ have to enter in "\\\\" as the value, at least in a Java
program. If we did ensure that "\" wasn't treated as an escape value,
but instead as a literal, I'm not sure how you would enter in actual
escape characters (like \n, \r, etc.). Granted, I'm not sure you would
/want/ to in an attribute value, but I know you would in element values.
So do we want the value of an Attribute to be set using different rules
than an Element? I'm not sure about this.

The more I think about it, the more I think this isn't a bug, but just
the way Java handles String values and escape sequences. Let me know
what you think.

-Brett

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org

From brett.mclaughlin at lutris.com  Thu Sep 14 09:00:16 2000
From: brett.mclaughlin at lutris.com (Brett McLaughlin)
Date: Fri Aug  6 17:04:57 2004
Subject: [jdom-interest] Namespace declarations
References: <3951281E.6EFD076D@metalab.unc.edu>
	 <3951085F.36695160@lutris.com> <p04330103b5e5924a5b09@[168.100.203.234]>
Message-ID: <39C0F610.1546862@lutris.com>


Elliotte Rusty Harold wrote:
> 
> I've been thinking about how to handle namespace declarations that
> don't map to any actual element or attribute in the document. These
> would customarily be prefixes used in attribute values or
> theoretically in element content.  I've only been able to develop two
> solutions to this problem, nether of which I like. Before I start
> writing code, I wanted to toss this out for further discussion.
> 
> Solution 1:
> 
>    Each element keeps track of namespace declarations (i.e. xmlns
> attributes) as well the namespace it actually uses. The builders
> would have to produce these form the input documents (not too hard)

No - and since we need to turn on namespace processing in SAX, this will
be even easier to do.

> and we'd need to add an API for attaching new ones to elements. The

Sure - this is the old addNamespaceDeclaration(Namespace ns) that we
once had (before the Namespace object, though).

> XMLOutputter would need to change as well. We could still (and I'd
> argue should still) not require people to add namespace declarations
> to elements just to declare prefixes actually used on elements and
> attributes. Instead the XMLOutputter could deduce these. It would,

Agreed. Existing code would work as is, because creating an Element in a
Namespace is implicitly adding the declaration. I would also argue that
we don't store the Element's own Namespace in the declarations Map (or
whatever); that would just contain additional ones.

> however, check to make sure that it wasn't duplicating an existing
> xmlns declaration.

This is where it gets hairy...

> 
> Thorniest issue with this approach: How do we handle conflicts
> between xmlns attributes and the prefixes actually used? More error
> checking and exception throwing is needed to prevent the possibility
> of using the same prefix or default namespace to refer to more than
> one URI within a single start tag. In fact we actually need this now,
> because it's possible for attributes and elements to define the same
> prefix in multiple ways within a start tag.

I think this is not so ugly a solution - the API is kept really clean
(one, maybe two [if you add a removeXXX()] new methods) is not bad. It
does make implementation a little tricky, but I think that's OK. The
hardest part, though, is the validation, as you point out. But then
again, it's also true that we need this anyway. So let's delve into that
more.

> 
> Solution 2:
> 
>    We allow attribute values to have a namespace URI attached to them.
> This would be optional. Most people wouldn't need to use this. The
> builders would still need to change to look for things that appeared
> to be prefixes in attribute values.  There's still a possibility of
> conflict between different prefixed names with the same prefix in a
> single start tag. Also I'm not sure it's at all intuitive.  Question:
> would there ever be more than one namespace prefix in a single
> attribute value?

This still doesn't solve, as far as I can see, the problem of an Element
having multiple namespace declarations on it, like the stylesheet
element in an XSL stylesheet. So I'm not sure it solves one of the
problems we have.

-Brett

> 
> I'd still like to come up with a solution that's cleaner than either
> of these. If anyone has any ideas I'd love to hear them.
> --
> 
> +-----------------------+------------------------+-------------------+
> | Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
> +-----------------------+------------------------+-------------------+
> |                  The XML Bible (IDG Books, 1999)                   |
> |              http://metalab.unc.edu/xml/books/bible/               |
> |   http://www.amazon.com/exec/obidos/ISBN=0764532367/cafeaulaitA/   |
> +----------------------------------+---------------------------------+
> |  Read Cafe au Lait for Java News:  http://metalab.unc.edu/javafaq/ |
> |  Read Cafe con Leche for XML News: http://metalab.unc.edu/xml/     |
> +----------------------------------+---------------------------------+
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org

From brett.mclaughlin at lutris.com  Thu Sep 14 09:01:07 2000
From: brett.mclaughlin at lutris.com (Brett McLaughlin)
Date: Fri Aug  6 17:04:57 2004
Subject: [jdom-interest] Modified XMLOutputter which optionally omits white 
 space
References: <NDBBLFGNKKGCBIJEAIJBEEOOCGAA.Brad.Morgan@e-pubcorp.com>
Message-ID: <39C0F643.80BF1DCC@lutris.com>


Brad Morgan wrote:
> 
> I've been struggling with the fact that JDOM trees include or exclude
> whitespace depending on the presence or absence of a DTD.
> 
> I think I understand this behavior but it doesn't make it any easier to deal
> with.
> 
> Since XMLOutputter has options to add formatting to the output XML file, I
> thought it should also have an option to remove (old) formatting as well.

So before I delve into this... this removes old formatting? Or overrides
it? or what?

-Brett

> 
> This appears to solve my problem where I have modified the document and
> possibly changed its structure as I added and removed elements.
> 
> I've attached my modified version below for consideration.  The original was
> current on Friday but I didn't check to see if any changes were made over
> the weekend.  From all the reading I've done about CVS, I think someone with
> the proper access can properly merge my changes.
> 
> Brad Morgan
> e-Publishing Corp.
> 
> Email: Brad.Morgan@e-pubcorp.com
> Phone: (719)593-7377 x35
> Fax: (719)593-2996
> 
> e-Publishing Corp. is a BroadVision company
> NOTICE: This message is intended only for the use of the Addressee and may
> contain information that is PRIVILEGED and CONFIDENTIAL. If you are not the
> intended recipient, dissemination of this communication is prohibited. If
> you have received this communication in error, please erase all copies of
> the message and its attachments and notify us immediately.
> 
>   ------------------------------------------------------------------------
>                         Name: XMLOutputter.java
>    XMLOutputter.java    Type: Java Source Files (application/x-unknown-content-type-java_auto_file)
>                     Encoding: quoted-printable

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org

From pvg at c-c-s.com  Thu Sep 14 10:21:14 2000
From: pvg at c-c-s.com (Peter V. Gadjokov)
Date: Fri Aug  6 17:04:57 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <704ECFDA88B3D311B5F000A0C959E5B601FBD8@adobo.c2labs.com>

>Well, there's one important benefit to the simple model.  If our
>internal data structures don't change but our public interfaces do
>(because we add new setters and such), then by assigning an sVUID we
>gain what could be called "short-term compatibility", that is
>compatibility until the variables change.

That's true, changing the svUID would work for this purpose and is simple in
implementation. At the same time, it's quite fragile - there is no way to
recover from trivial mistakes in the serialized form parameters
(declarations of transient, etc) without breaking existing archives that
have 'suffered innocently'. For instance, if a svUID were added to element
now, it would have to be changed the moment it is decided persisting the
cached text content is overkill (both relevant ivars are declared
non-transient right now). 

Perhaps it's useful to define three types of persistence lifespan and figure
out which one is best for JDOM. 

 - short term: as it is now, no svUIDs, useful for short-term persistence
and RMI. no guarantee of serialization format compatibility between JDOM
releases. 
  - 'medium term': as described by Jason above. most likely compatible
between minor revisions when no internal structures change and no serialized
classes, whether public or internal are refactored. 
  - long term:, as outlined in my initial post. Compatibility is explicitly
guaranteed between particular (possibly even major) releases. 

Is the effort to implement/support any of these significantly different? I
think they actually end up being about equally easy (or hard). There is no
getting away from explicit serialization methods, even in the short-term
case - the current implementation of Element, for instance, already has such
methods to deal with Namespace serialization. We're not really supporting
the RMI scenario very well yet since parents are implicitly  serialized
which makes it quite expensive to send over a single deep leaf element over
RMI. I'd say the implementation/maintenance cost is comparable for all
three, the last one being a bit more work in implementation and the first
two being somewhat more difficult to maintain well - their automatic nature
automates both good and bad serialized forms with equal ease. 

>Is serialization important as long-term storage?  
>Or should we just tell people to use *XML* as long term storage 
>(a very reasonable alternative)?

XML is a reasonable alternative although it is arguably more of an
orthogonal feature than alternative. A few of the obvious differences are: 

 A serialized archive contains enough information to exactly re-create a
serialized object graph - this is harder to do with XML, depending on output
options and other factors, the objects->xml and xml->objects operations
might not be idempotent.
 Java serialization is the 'native' serialization mechanism, the only one
supported by other core APIs, such as RMI and APIs based on RMI such as EJB,
Jini, etc (this might not be important for long term serialization but just
supporting RMI well requires about as much forethought and tweaking as
long-term serialization)
  The Java serialization facility supports storage formats other than the
built-in binary format - including XML, several XML-capable
Object(Output|Input)Stream implementations already exist. This would cover
the needs of those who want the format to be XML, but not necessarily the
XML that the Document actually represents. 
  The binary serialized format is probably smaller and almost certainly
faster to read/write/'parse'(*). This can be useful when storing JDOM XML
documents in, say, an RDBMS - one can store documents as smaller, more
efficiently read/written BLOBs. 

(*) I'll try to send out some informal numbers on this soon. 

In a word, I think it's worth supporting, but it's certainly a
'nice-to-have', it has more to do with JDOM being a good 'java citizen' as
opposed to processing XML, its primary purpose. 
   
>BTW, do any DOM impls support long-term serialization, or 
>would this be another JDOM extra?

I don't know of any that do but I haven't looked very carefully. Good
support for long-term serialization is fairly rare in general. It's
typically important in container classes and component assemblers/builders.
With the collections package covering most container class needs and
code-generation being the more fashionable choice for builders, the
automatic serialization mechanism is the most common choice. 

-pvg

From brett.mclaughlin at lutris.com  Thu Sep 14 10:05:44 2000
From: brett.mclaughlin at lutris.com (Brett McLaughlin)
Date: Fri Aug  6 17:04:57 2004
Subject: [jdom-interest] Re: Mailing List for JDOM
References: <200009141559.e8EFxbP18440@sm3.texas.rr.com>
Message-ID: <39C10568.2945764D@lutris.com>


Michael Engelhart wrote:
> 
> > The list is fixed... sorry I forgot to get back to you on that.
> Thanks - I saw your or Jason's post to the list about it.
> 
> > Hey, isn't your bug in getAttribute().getValue():
> essentially yes, but I was using the getAttributeValue() helper method.
> 
> > Isn't this simply a case of Java doing the right thing? The backslash
> > ("\") is an escape character, which means that anytime it goes into a
> > String, it essentially gets turned into an escape sequence. So "\\" is a
> > way to output "\" in a program. I think if you want "\\" in your output,
> > you /should/ have to enter in "\\\\" as the value, at least in a Java
> > program. If we did ensure that "\" wasn't treated as an escape value,
> > but instead as a literal, I'm not sure how you would enter in actual
> > escape characters (like \n, \r, etc.). Granted, I'm not sure you would
> > /want/ to in an attribute value, but I know you would in element values.
> > So do we want the value of an Attribute to be set using different rules
> > than an Element? I'm not sure about this.
> >
> > The more I think about it, the more I think this isn't a bug, but just
> > the way Java handles String values and escape sequences. Let me know
> > what you think.
> 
> Well the only reason it doesn't "seem" right to me is that for the last 6
> months I've been using Properties files and ResourceBundles to store these
> regular expressions and never had any trouble when calling something like
> ResourceBundle.getBundle("mybundle").getString("regex1")
> 
> I know ResourceBundle's internally use Properties objects but I'm not sure
> why it would work for ResourceBundle's and get escaped by JDOM?


Hmmm. I'm confused - I can't reproduce this behavior. Here's my XML
document:

<?xml version='1.0'?>

<DOCUMENT>
  <resource key="REGEX" value="m/[a-z].*\\W+/s" />
</DOCUMENT>


Here's my code:

import java.io.File;
import java.io.IOException;
import java.io.OutputStream;

import org.jdom.Attribute;
import org.jdom.Document;
import org.jdom.Element;
import org.jdom.JDOMException;
import org.jdom.input.SAXBuilder;
import org.jdom.output.XMLOutputter;

public class Test {

    /** Default SAX Driver class to use */
    private static final String DEFAULT_SAX_DRIVER_CLASS =
        "org.apache.xerces.parsers.SAXParser";

    /** SAX Driver Class to use */
    private String saxDriverClass;

    /** <code>{@link SAXBuilder}</code> instance to use */
    private SAXBuilder builder;

    /**
     * <p>
     * This will create an instance of <code>{@link SAXBuilder}</code>
     *   for use in the rest of this program.
     * </p>
     *
     * @param saxDriverClass <code>String</code> name of driver class to
use.
     */
    public Test(String saxDriverClass) {
        this.saxDriverClass = saxDriverClass;
        builder = new SAXBuilder(saxDriverClass);
    }

    /**
     * <p>
     * This will parse the specified filename using SAX and the
     *   SAX driver class specified in the constructor.
     * </p>
     *
     * @param filename <code>String</code> name of file to parse.
     * @param out <code>OutputStream</code> to output to.
     */
    public void testBuilder(String filename, OutputStream out) 
        throws IOException, JDOMException {

        // Build the JDOM Document
        Document doc = builder.build(new File(filename));

        Element testElement = doc.getRootElement().getChild("resource");
        System.out.println(testElement.getName());
        System.out.println(testElement.getAttributeValue("value"));
    }

    /**
     * <p>
     * This provides a static entry point for creating a JDOM
     *   <code>{@link Document}</code> object using a SAX 2.0
     *   parser (an <code>XMLReader</code> implementation).
     * </p>
     *
     * @param args <code>String[]</code>
     *        <ul>
     *         <li>First argument: filename of XML document to
parse</li>
     *         <li>Second argument: optional name of SAX Driver
class</li>
     *        </ul>
     */
    public static void main(String[] args) {
        if ((args.length != 1) && (args.length != 2)) {
            System.out.println("Usage: java
org.jdom.examples.io.SAXBuilderTest " +
                               "[XML document filename] ([SAX Driver
Class])");
            return;
        }

        // Load filename and SAX driver class
        String filename = args[0];
        String saxDriverClass = DEFAULT_SAX_DRIVER_CLASS;
        if (args.length == 2) {
            saxDriverClass = args[1];
        }

        // Create an instance of the tester and test
        try {
            Test test = new Test(saxDriverClass);
            test.testBuilder(filename, System.out);
        } catch (JDOMException e) {
            if (e.getRootCause() != null) {
                e.getRootCause().printStackTrace();
            } else {
                e.printStackTrace();
            }
        } catch (Exception e) {
            e.printStackTrace();
        }    
    }
}

My result is:


C:\projects\dev\jdom\build\classes>java Test inline.xml
resource
m/[a-z].*\\W+/s

So I'm not getting the same problem. Can you get the latest JDOM from
CVS and try this?

Thanks,
Brett

> 
> Any ideas?
> 
> thanks a lot
> 
> Mike
> 
> > >>>>>>>
> > I have simple XML file with elements like this:
> >
> > <resource key="REGEX" value="m/[a-z].*\\W+/s" />
> >
> >
> > when I read it in and call Element.getAttributeValue("value"), I get
> > this
> > as the string:
> > m/[a-z].*\W+/s
> >
> > where the original has an escaped "\\" in it:
> > m/[a-z].*\\W+/s
> >
> > Any idea what gives?
> > <<<<<<<
> >  >

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org

From guru at edamame.stinky.com  Thu Sep 14 05:49:52 2000
From: guru at edamame.stinky.com (Alex Chaffee)
Date: Fri Aug  6 17:04:57 2004
Subject: [jdom-interest] getChildren() vs getElements()
Message-ID: <20000914054952.G18335@edamame.stinky.com>

Wasn't there a discussion a few months ago about renaming
getChildren() to getElements()?  This Solomon-like solution was
provided by somebody smart, I think James.

Recap:

element.getChildren()
	ambiguous; implies that it gets Attributes etc. :-(

element.getChildElements()
	too long to type :-(

element.getElements()
	brief; no way it can be misinterpreted :-)

Was this just forgotten, or was there a reason to keep getChildren
that I missed?

(We could deprecate getChildren for a few months before the 1.0
release to allow migration.)

 - Alex

P.S. This is orthogonal to the current "Element implements List"
discussion.  BTW, I think it should not implement List, for this very
reason: there is an ambiguity as to what the members of that list
would be (elements or mixed or elements+attributes or ...)


-- 
Alex Chaffee                       mailto:alex@jguru.com
jGuru - Java News and FAQs         http://www.jguru.com/alex/
Creator of Gamelan                 http://www.gamelan.com/
Founder of Purple Technology       http://www.purpletech.com/
Curator of Stinky Art Collective   http://www.stinky.com/

From jhunter at collab.net  Thu Sep 14 13:31:05 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:04:57 2004
Subject: [jdom-interest] getChildren() vs getElements()
References: <20000914054952.G18335@edamame.stinky.com>
Message-ID: <39C13589.8F5763F7@collab.net>

> Wasn't there a discussion a few months ago about renaming
> getChildren() to getElements()?  This Solomon-like solution was
> provided by somebody smart, I think James.
> 
> Was this just forgotten, or was there a reason to keep getChildren
> that I missed?

We couldn't come to agreement, so we postponed until after beta5.

-jh-

From brett.mclaughlin at lutris.com  Thu Sep 14 14:37:11 2000
From: brett.mclaughlin at lutris.com (Brett McLaughlin)
Date: Fri Aug  6 17:04:57 2004
Subject: [jdom-interest] getChildren() vs getElements()
References: <20000914054952.G18335@edamame.stinky.com> <39C13589.8F5763F7@collab.net>
Message-ID: <39C14507.D7D7CDD4@lutris.com>


Jason Hunter wrote:
> 
> > Wasn't there a discussion a few months ago about renaming
> > getChildren() to getElements()?  This Solomon-like solution was
> > provided by somebody smart, I think James.
> >
> > Was this just forgotten, or was there a reason to keep getChildren
> > that I missed?
> 
> We couldn't come to agreement, so we postponed until after beta5.

I'd rather get it in now... what do you think? That way, no method names
change in beta 5+, which we have been telling people - small changes.
That would be big, though, so I'd rather do it now.

+1 on getChildElements(), or worst case getElements()

-Brett

> 
> -jh-
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org

From ndjc at continuus.com  Thu Sep 14 15:13:50 2000
From: ndjc at continuus.com (Nick Crossley)
Date: Fri Aug  6 17:04:57 2004
Subject: [jdom-interest] XMLOutputter and empty elements
Message-ID: <001101c01e99$1029fa70$070aa8c0@continuus.com>

> Wow. This was such a good and simple suggestion that I put it into CVS
> right now. Get the latest version, Nick, and do this:
> XMLOutputter outputter = new XMLOutputter();
> outputter.setExpandEmptyElements(true);
> outputter.output(myDoc);
> Now aren't I a nice guy ;-)

Yes!  That works fine, thanks!

Nick.



From Haruki_Zaemon at hotmail.com  Thu Sep 14 15:31:22 2000
From: Haruki_Zaemon at hotmail.com (Simon Harris)
Date: Fri Aug  6 17:04:57 2004
Subject: [jdom-interest] getChildren() vs getElements()
References: <20000914054952.G18335@edamame.stinky.com> <39C13589.8F5763F7@collab.net> <39C14507.D7D7CDD4@lutris.com>
Message-ID: <OE37hEUsebmspH2q6Dq000000c1@hotmail.com>

+1 getChildElements()

----- Original Message -----
From: "Brett McLaughlin" <brett.mclaughlin@lutris.com>
Cc: <jdom-interest@jdom.org>
Sent: Friday, September 15, 2000 8:37 AM
Subject: Re: [jdom-interest] getChildren() vs getElements()


>
>
> Jason Hunter wrote:
> >
> > > Wasn't there a discussion a few months ago about renaming
> > > getChildren() to getElements()?  This Solomon-like solution was
> > > provided by somebody smart, I think James.
> > >
> > > Was this just forgotten, or was there a reason to keep getChildren
> > > that I missed?
> >
> > We couldn't come to agreement, so we postponed until after beta5.
>
> I'd rather get it in now... what do you think? That way, no method names
> change in beta 5+, which we have been telling people - small changes.
> That would be big, though, so I'd rather do it now.
>
> +1 on getChildElements(), or worst case getElements()
>
> -Brett
>
> >
> > -jh-
> > _______________________________________________
> > To control your jdom-interest membership:
> >
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com
>
> --
> Brett McLaughlin, Enhydra Strategist
> Lutris Technologies, Inc.
> 1200 Pacific Avenue, Suite 300
> Santa Cruz, CA 95060 USA
> http://www.lutris.com
> http://www.enhydra.org
> _______________________________________________
> To control your jdom-interest membership:
>
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com
>

From bob at accurev.com  Thu Sep 14 18:21:21 2000
From: bob at accurev.com (bob)
Date: Fri Aug  6 17:04:57 2004
Subject: [jdom-interest] getChildren() vs getElements()
In-Reply-To: <OE37hEUsebmspH2q6Dq000000c1@hotmail.com>
Message-ID: <Pine.LNX.3.96.1000914212006.12780w-100000@exeter.exeter.org>

Likweise, I prefer getChildElements() over getChildren()
[since Attributes theoretically are children] and getElements(),
since getElements() doesn't tell you how deep it goes.

So, if my vote counts, +1 getChildElements().

	-bob

On Fri, 15 Sep 2000, Simon Harris wrote:

> +1 getChildElements()
> 
> ----- Original Message -----
> From: "Brett McLaughlin" <brett.mclaughlin@lutris.com>
> Cc: <jdom-interest@jdom.org>
> Sent: Friday, September 15, 2000 8:37 AM
> Subject: Re: [jdom-interest] getChildren() vs getElements()
> 
> 
> >
> >
> > Jason Hunter wrote:
> > >
> > > > Wasn't there a discussion a few months ago about renaming
> > > > getChildren() to getElements()?  This Solomon-like solution was
> > > > provided by somebody smart, I think James.
> > > >
> > > > Was this just forgotten, or was there a reason to keep getChildren
> > > > that I missed?
> > >
> > > We couldn't come to agreement, so we postponed until after beta5.
> >
> > I'd rather get it in now... what do you think? That way, no method names
> > change in beta 5+, which we have been telling people - small changes.
> > That would be big, though, so I'd rather do it now.
> >
> > +1 on getChildElements(), or worst case getElements()
> >
> > -Brett
> >
> > >
> > > -jh-
> > > _______________________________________________
> > > To control your jdom-interest membership:
> > >
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
> t.com
> >
> > --
> > Brett McLaughlin, Enhydra Strategist
> > Lutris Technologies, Inc.
> > 1200 Pacific Avenue, Suite 300
> > Santa Cruz, CA 95060 USA
> > http://www.lutris.com
> > http://www.enhydra.org
> > _______________________________________________
> > To control your jdom-interest membership:
> >
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
> t.com
> >
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
> 


From pvg at c-c-s.com  Thu Sep 14 19:10:23 2000
From: pvg at c-c-s.com (Peter V. Gadjokov)
Date: Fri Aug  6 17:04:57 2004
Subject: [jdom-interest] getChildren() vs getElements()
Message-ID: <704ECFDA88B3D311B5F000A0C959E5B601FBDA@adobo.c2labs.com>

Another +1 on getChildElements (with a recommendation to upgrade to emacs
and use dabbrev expansion for those who don't like typing long method names
:).

-pvg

-----Original Message-----
From: Brett McLaughlin [mailto:brett.mclaughlin@lutris.com]
Sent: Thursday, September 14, 2000 2:37 PM
Cc: jdom-interest@jdom.org
Subject: Re: [jdom-interest] getChildren() vs getElements()




Jason Hunter wrote:
> 
> > Wasn't there a discussion a few months ago about renaming
> > getChildren() to getElements()?  This Solomon-like solution was
> > provided by somebody smart, I think James.
> >
> > Was this just forgotten, or was there a reason to keep getChildren
> > that I missed?
> 
> We couldn't come to agreement, so we postponed until after beta5.

I'd rather get it in now... what do you think? That way, no method names
change in beta 5+, which we have been telling people - small changes.
That would be big, though, so I'd rather do it now.

+1 on getChildElements(), or worst case getElements()

-Brett

> 
> -jh-
> _______________________________________________
> To control your jdom-interest membership:
>
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org
_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com

From Fred_Trimble at vertexinc.com  Fri Sep 15 07:37:00 2000
From: Fred_Trimble at vertexinc.com (Fred_Trimble@vertexinc.com)
Date: Fri Aug  6 17:04:57 2004
Subject: [jdom-interest] SAXOutputter
Message-ID: <000BC0DC.N22209@vertexinc.com>

I'm new to the jdom-interest mailing list. Does anyone know the
status of org.jdom.SAXOutputter? I searched the archives, but
didn't find anything. My apologies if this has already been addressed.

Regards, and thank you in advance,
- Fred



From dsmiley at mitre.org  Fri Sep 15 08:31:06 2000
From: dsmiley at mitre.org (David W. Smiley)
Date: Fri Aug  6 17:04:57 2004
Subject: [jdom-interest] getChildren() vs getElements()
References: <200009142236.QAA06956@dorothy.denveronline.net>
Message-ID: <39C240BA.8FDE3F21@mitre.org>

> I'd rather get it in now... what do you think? That way, no method names
> change in beta 5+, which we have been telling people - small changes.
> That would be big, though, so I'd rather do it now.
> 
> +1 on getChildElements(), or worst case getElements()
> 
> -Brett

+1 on this for me too.

-- David Smiley


From sshanny at eziba.com  Fri Sep 15 09:33:01 2000
From: sshanny at eziba.com (Sean Shanny)
Date: Fri Aug  6 17:04:58 2004
Subject: [jdom-interest] I just pulled down the latest source via WINCVS
Message-ID: <39C24F3D.AD7718E6@eziba.com>

to my Win2K machine.  I run the build.bat script and get the following
error:

d:\cvs\jdom\jdom>build
JDOM Build System
-------------------
Building with classpath
d:\jdk1.3\lib\tools.jar;.\lib\xerces.jar;.\lib\ant.jar;
Starting Ant...
Buildfile: build.xml

init:
----------- JDOM 1.0beta5 [2000] ------------

prepare:
    [mkdir] Created dir: D:\cvs\jdom\jdom\build

prepare-src:
    [mkdir] Created dir: D:\cvs\jdom\jdom\build\src
    [mkdir] Created dir: D:\cvs\jdom\jdom\build\classes
  [copydir] Copying 29 files to D:\cvs\jdom\jdom\build\src

collections:

compile:
    [javac] Compiling 29 source files to D:\cvs\jdom\jdom\build\classes

package:

BUILD FAILED

build.xml:161: java.io.FileNotFoundException: D:\cvs\jdom\jdom\build.bat
(Access
 is denied)
java.io.FileNotFoundException: D:\cvs\jdom\jdom\build.bat (Access is
denied)
        at java.io.FileOutputStream.open(Native Method)
        at java.io.FileOutputStream.<init>(FileOutputStream.java:102)
        at java.io.FileOutputStream.<init>(FileOutputStream.java:62)
        at java.io.FileOutputStream.<init>(FileOutputStream.java:132)
        at
org.apache.tools.ant.taskdefs.FixCRLF.execute(FixCRLF.java:364)
        at org.apache.tools.ant.Target.execute(Target.java:132)
        at org.apache.tools.ant.Project.runTarget(Project.java:717)
        at org.apache.tools.ant.Project.executeTarget(Project.java:448)
        at org.apache.tools.ant.Project.executeTargets(Project.java:422)

        at org.apache.tools.ant.Main.runBuild(Main.java:279)
        at org.apache.tools.ant.Main.main(Main.java:107)

Total time: 7 seconds


If someone could point out the error of my ways I would be most
appreciative.

--sean

--
Sean Shanny
Principal Software Engineer
eZiba.com
phone: 413-664-9999 ext. 146
fax: 413-664-9990
e-mail: sshanny@eziba.com

Shop http://www.eZiba.com where every object tells a story.



From philip.nelson at omniresources.com  Fri Sep 15 10:39:16 2000
From: philip.nelson at omniresources.com (philip.nelson@omniresources.com)
Date: Fri Aug  6 17:04:58 2004
Subject: [jdom-interest] getChildren() vs getElements()
Message-ID: <DF5018B3C986D11196FF0060089A903C2BFE9D@OMNIGBWWW>

> > I'd rather get it in now... what do you think? That way, no 
> method names
> > change in beta 5+, which we have been telling people - 
> small changes.

great, let's settle this.

> > That would be big, though, so I'd rather do it now.
> > 
> > +1 on getChildElements(), or worst case getElements()

Here I can agree with getChildElements() because we are still consistent
with the name getChild() which returns a (strongly typed) Element wheras
getChildren() returns a List of Objects and only the docs can tell you what
to expect.

From sshanny at eziba.com  Fri Sep 15 11:00:04 2000
From: sshanny at eziba.com (Sean Shanny)
Date: Fri Aug  6 17:04:58 2004
Subject: [jdom-interest] I just pulled down the latest source via WINCVS
References: <39C24F3D.AD7718E6@eziba.com>
Message-ID: <39C263A4.8EADA337@eziba.com>

To all,

I have figured this out.  I have my cvs client set up to check things out read-only.
The new directives in the build.xml file that fix crlf stuff obviously won't work if
the file is read-only.  Little gotcha there.

Sorry for the post.

--sean

Sean Shanny wrote:

> to my Win2K machine.  I run the build.bat script and get the following
> error:
>
> d:\cvs\jdom\jdom>build
> JDOM Build System
> -------------------
> Building with classpath
> d:\jdk1.3\lib\tools.jar;.\lib\xerces.jar;.\lib\ant.jar;
> Starting Ant...
> Buildfile: build.xml
>
> init:
> ----------- JDOM 1.0beta5 [2000] ------------
>
> prepare:
>     [mkdir] Created dir: D:\cvs\jdom\jdom\build
>
> prepare-src:
>     [mkdir] Created dir: D:\cvs\jdom\jdom\build\src
>     [mkdir] Created dir: D:\cvs\jdom\jdom\build\classes
>   [copydir] Copying 29 files to D:\cvs\jdom\jdom\build\src
>
> collections:
>
> compile:
>     [javac] Compiling 29 source files to D:\cvs\jdom\jdom\build\classes
>
> package:
>
> BUILD FAILED
>
> build.xml:161: java.io.FileNotFoundException: D:\cvs\jdom\jdom\build.bat
> (Access
>  is denied)
> java.io.FileNotFoundException: D:\cvs\jdom\jdom\build.bat (Access is
> denied)
>         at java.io.FileOutputStream.open(Native Method)
>         at java.io.FileOutputStream.<init>(FileOutputStream.java:102)
>         at java.io.FileOutputStream.<init>(FileOutputStream.java:62)
>         at java.io.FileOutputStream.<init>(FileOutputStream.java:132)
>         at
> org.apache.tools.ant.taskdefs.FixCRLF.execute(FixCRLF.java:364)
>         at org.apache.tools.ant.Target.execute(Target.java:132)
>         at org.apache.tools.ant.Project.runTarget(Project.java:717)
>         at org.apache.tools.ant.Project.executeTarget(Project.java:448)
>         at org.apache.tools.ant.Project.executeTargets(Project.java:422)
>
>         at org.apache.tools.ant.Main.runBuild(Main.java:279)
>         at org.apache.tools.ant.Main.main(Main.java:107)
>
> Total time: 7 seconds
>
> If someone could point out the error of my ways I would be most
> appreciative.
>
> --sean
>
> --
> Sean Shanny
> Principal Software Engineer
> eZiba.com
> phone: 413-664-9999 ext. 146
> fax: 413-664-9990
> e-mail: sshanny@eziba.com
>
> Shop http://www.eZiba.com where every object tells a story.
>
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com

--
Sean Shanny
Principal Software Engineer
eZiba.com
phone: 413-664-9999 ext. 146
fax: 413-664-9990
e-mail: sshanny@eziba.com

Shop http://www.eZiba.com where every object tells a story.



From jhunter at collab.net  Fri Sep 15 11:20:30 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:04:58 2004
Subject: [jdom-interest] SAXOutputter
References: <000BC0DC.N22209@vertexinc.com>
Message-ID: <39C2686E.7A8987A4@collab.net>

> I'm new to the jdom-interest mailing list. Does anyone know the
> status of org.jdom.SAXOutputter? I searched the archives, but
> didn't find anything. My apologies if this has already been addressed.
> 
> Regards, and thank you in advance,
> - Fred

It's waiting for someone to come along and write it.  Brett and I will
get to it eventually but we are concentrating our efforts on other
things first.  If you want to write it, shouldn't be that hard and the
list is good at providing support.

-jh-

From brett.mclaughlin at lutris.com  Fri Sep 15 11:55:36 2000
From: brett.mclaughlin at lutris.com (Brett McLaughlin)
Date: Fri Aug  6 17:04:58 2004
Subject: [jdom-interest] SAXOutputter
References: <000BC0DC.N22209@vertexinc.com>
Message-ID: <39C270A8.DD640039@lutris.com>


Fred_Trimble@vertexinc.com wrote:
> 
> I'm new to the jdom-interest mailing list. Does anyone know the
> status of org.jdom.SAXOutputter? I searched the archives, but
> didn't find anything. My apologies if this has already been addressed.

Hey Fred-

  Honestly, not much progress. It's in there to indicate what we want to
do, but since nobody has voiced much interest, it hasn't been worked on.
I think it was essentially assumed that I would do that; most people
here are a lot more familiar with DOM, and not as much so with SAX. If
you want to start work on it, that would be terrific!

-Brett

> 
> Regards, and thank you in advance,
> - Fred
> 
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org

From jhunter at collab.net  Fri Sep 15 11:51:18 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:04:58 2004
Subject: [jdom-interest] I just pulled down the latest source via WINCVS
References: <39C24F3D.AD7718E6@eziba.com> <39C263A4.8EADA337@eziba.com>
Message-ID: <39C26FA6.CBA9463@collab.net>

> I have figured this out.  I have my cvs client set up to check 
> things out read-only. The new directives in the build.xml file 
> that fix crlf stuff obviously won't work if
> the file is read-only.  Little gotcha there.

Makes sense.  I think we need a "make dist" target that makes a
distribution and that's the target that should have the fixcrlf.  It's
only when the code might leave your machine that you need to worry about
such things.

-jh-

From jhunter at collab.net  Fri Sep 15 11:56:22 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:04:58 2004
Subject: [jdom-interest] getChildren() vs getElements()
References: <DF5018B3C986D11196FF0060089A903C2BFE9D@OMNIGBWWW>
Message-ID: <39C270D6.21A22CE8@collab.net>

> Here I can agree with getChildElements() because we are 
> still consistent with the name getChild() which returns a 
> (strongly typed) Element wheras getChildren() returns a List 
> of Objects and only the docs can tell you what to expect.

The proposal isn't:

getChildElements()
getChild()

The proposal is:

getChildElements()
getChildElement()

The former wouldn't be consistent.  One problem with the latter is it's
almost *too* consistent and hard to differentiate.  It's one reason I
prefer getChild() / getChildren().  I also prefer it because it leaves
the option to have getChildTextTrim() which I find really useful.  If we
go with getChildElement() then it'd be getChildElementTextTrim() and
that's just too many nouns to be understandable.

-jh-

From philip.nelson at omniresources.com  Fri Sep 15 12:22:26 2000
From: philip.nelson at omniresources.com (philip.nelson@omniresources.com)
Date: Fri Aug  6 17:04:58 2004
Subject: [jdom-interest] getChildren() vs getElements()
Message-ID: <DF5018B3C986D11196FF0060089A903C2BFEA2@OMNIGBWWW>

> The proposal isn't:
> 
> getChildElements()
> getChild()
> 
> The proposal is:
> 
> getChildElements()
> getChildElement()
> 

oh boy...

don't forget getElements(), getElement() 

> The former wouldn't be consistent.  One problem with the 
> latter is it's
> almost *too* consistent and hard to differentiate.  It's one reason I
> prefer getChild() / getChildren().  I also prefer it because it leaves
> the option to have getChildTextTrim() which I find really 
> useful.  If we
> go with getChildElement() then it'd be getChildElementTextTrim() and
> that's just too many nouns to be understandable.

As I did before, I agree with this now.  getChild() is perfectly clear.
Those who dislike getChildren have a better case for a name change and
Alex's post was just on that one.

I really don't see this decision making anyone unable to figure out JDOM or
this decision putting JDOM on the long list of good ideas whose time never
came or any other dire consequences of this decision.  So, I will abstain
from further votes and recode (a minor effort) as needed when it happens.
For those to whom it matters much more than me, good luck ;^)

From will.glozer at jda.com  Fri Sep 15 12:38:39 2000
From: will.glozer at jda.com (Will Glozer)
Date: Fri Aug  6 17:04:58 2004
Subject: [jdom-interest] getChildren() vs getElements()
Message-ID: <6BC14873F507D3119B8C0090273C434904BEC6A0@jdasoftware.com>

I agree completely, getChild()/getChildren() is more 
understandable and clean imho.  It is nice to have
verbose method names, but there is a point when it
becomes far too verbose.

Regards,
Will

-----Original Message-----
From: Jason Hunter [mailto:jhunter@collab.net]
Sent: Friday, September 15, 2000 11:56 AM
To: philip.nelson@omniresources.com
Cc: 	
Subject: Re: [jdom-interest] getChildren() vs getElements()


> Here I can agree with getChildElements() because we are 
> still consistent with the name getChild() which returns a 
> (strongly typed) Element wheras getChildren() returns a List 
> of Objects and only the docs can tell you what to expect.

The proposal isn't:

getChildElements()
getChild()

The proposal is:

getChildElements()
getChildElement()

The former wouldn't be consistent.  One problem with the latter is it's
almost *too* consistent and hard to differentiate.  It's one reason I
prefer getChild() / getChildren().  I also prefer it because it leaves
the option to have getChildTextTrim() which I find really useful.  If we
go with getChildElement() then it'd be getChildElementTextTrim() and
that's just too many nouns to be understandable.

-jh-
_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com

From brett.mclaughlin at lutris.com  Fri Sep 15 13:33:56 2000
From: brett.mclaughlin at lutris.com (Brett McLaughlin)
Date: Fri Aug  6 17:04:58 2004
Subject: [jdom-interest] getChildren() vs getElements()
References: <6BC14873F507D3119B8C0090273C434904BEC6A0@jdasoftware.com>
Message-ID: <39C287B4.B7E6A37@lutris.com>


Will Glozer wrote:
> 
> I agree completely, getChild()/getChildren() is more
> understandable and clean imho.  It is nice to have
> verbose method names, but there is a point when it
> becomes far too verbose.

Except when they are wrong. getChild() implies a Child will get
returned, which does not mean an Element in XML. This has nothing to do
with verbosity, and I think it's funny that so many people think that a
child is equal to an Element in XML. It shows that we are only
propgating this incorrect assumption. But, that's certainly people's
right ;-)

And yes, getChildren() is not understandable. Even the people who go to
the Javadocs (and contrary to what some folks are saying, it's not so
common - most people don't even know how to build them, as earlier posts
brought to light) will see "List." Even a cursory reading of the XML
spec would lead you to think that List is not just Elements.

-Brett

> 
> Regards,
> Will
> 
> -----Original Message-----
> From: Jason Hunter [mailto:jhunter@collab.net]
> Sent: Friday, September 15, 2000 11:56 AM
> To: philip.nelson@omniresources.com
> Cc:
> Subject: Re: [jdom-interest] getChildren() vs getElements()
> 
> > Here I can agree with getChildElements() because we are
> > still consistent with the name getChild() which returns a
> > (strongly typed) Element wheras getChildren() returns a List
> > of Objects and only the docs can tell you what to expect.
> 
> The proposal isn't:
> 
> getChildElements()
> getChild()
> 
> The proposal is:
> 
> getChildElements()
> getChildElement()
> 
> The former wouldn't be consistent.  One problem with the latter is it's
> almost *too* consistent and hard to differentiate.  It's one reason I
> prefer getChild() / getChildren().  I also prefer it because it leaves
> the option to have getChildTextTrim() which I find really useful.  If we
> go with getChildElement() then it'd be getChildElementTextTrim() and
> that's just too many nouns to be understandable.
> 
> -jh-
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
> t.com
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org

From Brad.Morgan at e-pubcorp.com  Fri Sep 15 14:36:31 2000
From: Brad.Morgan at e-pubcorp.com (Brad Morgan)
Date: Fri Aug  6 17:04:58 2004
Subject: [jdom-interest] CVS Repository source snapshots
In-Reply-To: <39C263A4.8EADA337@eziba.com>
Message-ID: <NDBBLFGNKKGCBIJEAIJBMEPICGAA.Brad.Morgan@e-pubcorp.com>

The web page says these snapshots are updated daily.  This doesn't seem to
be the case.  How often should these snapshots be updated?

Thanks,

Brad Morgan
e-Publishing Corp.

Email: Brad.Morgan@e-pubcorp.com
Phone: (719)593-7377 x35
Fax: (719)593-2996

e-Publishing Corp. is a BroadVision company
NOTICE: This message is intended only for the use of the Addressee and may
contain information that is PRIVILEGED and CONFIDENTIAL. If you are not the
intended recipient, dissemination of this communication is prohibited. If
you have received this communication in error, please erase all copies of
the message and its attachments and notify us immediately.


From pvg at c-c-s.com  Fri Sep 15 16:03:15 2000
From: pvg at c-c-s.com (Peter V. Gadjokov)
Date: Fri Aug  6 17:04:58 2004
Subject: [jdom-interest] I just pulled down the latest source via WINC
	VS
Message-ID: <704ECFDA88B3D311B5F000A0C959E5B601FBDC@adobo.c2labs.com>

Maybe I'm not quite understanding the original problem, but is fixcrlf
really needed? Id mofifies files checked into the repository at build-time,
which is unusual and unexpected, usually.  Doesn't checking in a build.bat
and a build.sh as binary with the correct line endings take care of this? I
noticed tomcat has a similar directive so there is probably some reason for
doing this I'm missing.


-----Original Message-----
From: Jason Hunter [mailto:jhunter@collab.net]
Sent: Friday, September 15, 2000 11:51 AM
To: Sean Shanny
Cc: jdom-interest@jdom.org
Subject: Re: [jdom-interest] I just pulled down the latest source via
WINCVS


> I have figured this out.  I have my cvs client set up to check 
> things out read-only. The new directives in the build.xml file 
> that fix crlf stuff obviously won't work if
> the file is read-only.  Little gotcha there.

Makes sense.  I think we need a "make dist" target that makes a
distribution and that's the target that should have the fixcrlf.  It's
only when the code might leave your machine that you need to worry about
such things.

-jh-
_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com

From jhunter at collab.net  Fri Sep 15 16:58:12 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:04:58 2004
Subject: [jdom-interest] I just pulled down the latest source via WINCVS
References: <704ECFDA88B3D311B5F000A0C959E5B601FBDC@adobo.c2labs.com>
Message-ID: <39C2B794.E6841620@collab.net>

"Peter V. Gadjokov" wrote:
> Doesn't checking in a build.bat and a build.sh as binary with the 
> correct line endings take care of this? 

Prob'ly so, but this has the slightly nicer behavior that you can always
view/edit the files on either system.  That's esp nice for developers
who need to change a classpath in both files, for example.

The directive will be really useful when packaging for distribution
since you'll have .txt files and .java files that need to be converted.

-jh-

From jools at jools.org  Fri Sep 15 17:08:08 2000
From: jools at jools.org (Jools Enticknap)
Date: Fri Aug  6 17:04:58 2004
Subject: [jdom-interest] CVS Repository source snapshots
In-Reply-To: <NDBBLFGNKKGCBIJEAIJBMEPICGAA.Brad.Morgan@e-pubcorp.com>
Message-ID: <Pine.LNX.4.10.10009160050200.13288-100000@www.nmemonix.com>


On Fri, 15 Sep 2000, Brad Morgan wrote:

> The web page says these snapshots are updated daily.  This doesn't seem to
> be the case.  How often should these snapshots be updated?

Daily :-) at 00:00 UTC, and seeing as it's 00:47 UTC now, then the files
will have been updated.

BTW, somebody emailed me to say that the archives were'nt being updated
last week, however we later found out that he had a caching proxy in the
way. 



--Jools (The CVS guy)








From Haruki_Zaemon at hotmail.com  Fri Sep 15 18:09:27 2000
From: Haruki_Zaemon at hotmail.com (Simon Harris)
Date: Fri Aug  6 17:04:58 2004
Subject: [jdom-interest] getChildren() vs getElements()
References: <6BC14873F507D3119B8C0090273C434904BEC6A0@jdasoftware.com>
Message-ID: <OE32LbaENFGcMd5NfOI00000d5e@hotmail.com>

Hey I'll go with this too. My vote is for consitency not any name in
particular :)

Simon.

----- Original Message -----
From: "Will Glozer" <will.glozer@jda.com>
To: <jdom-interest@jdom.org>
Sent: Saturday, September 16, 2000 5:38 AM
Subject: RE: [jdom-interest] getChildren() vs getElements()


> I agree completely, getChild()/getChildren() is more
> understandable and clean imho.  It is nice to have
> verbose method names, but there is a point when it
> becomes far too verbose.
>
> Regards,
> Will
>
> -----Original Message-----
> From: Jason Hunter [mailto:jhunter@collab.net]
> Sent: Friday, September 15, 2000 11:56 AM
> To: philip.nelson@omniresources.com
> Cc:
> Subject: Re: [jdom-interest] getChildren() vs getElements()
>
>
> > Here I can agree with getChildElements() because we are
> > still consistent with the name getChild() which returns a
> > (strongly typed) Element wheras getChildren() returns a List
> > of Objects and only the docs can tell you what to expect.
>
> The proposal isn't:
>
> getChildElements()
> getChild()
>
> The proposal is:
>
> getChildElements()
> getChildElement()
>
> The former wouldn't be consistent.  One problem with the latter is it's
> almost *too* consistent and hard to differentiate.  It's one reason I
> prefer getChild() / getChildren().  I also prefer it because it leaves
> the option to have getChildTextTrim() which I find really useful.  If we
> go with getChildElement() then it'd be getChildElementTextTrim() and
> that's just too many nouns to be understandable.
>
> -jh-
> _______________________________________________
> To control your jdom-interest membership:
>
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
> t.com
> _______________________________________________
> To control your jdom-interest membership:
>
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com
>

From pvg at c-c-s.com  Fri Sep 15 17:27:31 2000
From: pvg at c-c-s.com (Peter V. Gadjokov)
Date: Fri Aug  6 17:04:58 2004
Subject: [jdom-interest] I just pulled down the latest source via WINC
	VS
Message-ID: <704ECFDA88B3D311B5F000A0C959E5B601FBE5@adobo.c2labs.com>


> Prob'ly so, but this has the slightly nicer behavior that you 
> can always
> view/edit the files on either system.  That's esp nice for developers
> who need to change a classpath in both files, for example.

Yeah that makes sense, although both scripts in question have an
ADDITIONALCLASSPATH evar and should not require editing. Plus, Java
programmers typically use line-ending understanding/preserving editors (I
would hope) so the editing problem is solved elsewhere. I do think changing
repository files on the fly, locally, during a build, is just questionable
and surprising practice, the making of local files read-only is a pretty
common SCM feature (not a default in CVS though). 
 
> The directive will be really useful when packaging for distribution
> since you'll have .txt files and .java files that need to be 
> converted.

Yep, and packaging for distribution would typically not modify repo files in
place. 

All the above though, is really just opinion, I'm perfectly fine with the
way it is (nobody should be using WinCVS anyway :) - thanks for clarifying
the issue, I wasn't sure I wasn't missing some aspect of it.

-pvg

From guru at edamame.stinky.com  Fri Sep 15 11:16:39 2000
From: guru at edamame.stinky.com (Alex Chaffee)
Date: Fri Aug  6 17:04:58 2004
Subject: [jdom-interest] getChildren() vs getElements()
In-Reply-To: <20000914054952.G18335@edamame.stinky.com>; from guru@edamame.stinky.com on Thu, Sep 14, 2000 at 05:49:52AM -0700
References: <20000914054952.G18335@edamame.stinky.com>
Message-ID: <20000915111639.H23172@edamame.stinky.com>

Wait a second.  The +1s are coming fast and furious but...

I think getChildElements() is too verbose and also redundant.  Of
course it's a child element; what other kind of element would it
return?  A parent element?  A cousin? :-)

getElements() is not ambiguous.  It doesn't imply that it recurses any
more than getChildren() implies that it recurses.  Once you accept
that an element can contain elements, it is not confusing (it only
sounds self-referential, but it's not).

The issue is terminological: there are many "children" of an element,
but only some of them are elements.  Thus getElements() should return
the children that are elements, getAttributes() should return the
children that are attributes, and so forth.


So:

getChildren() should be renamed getElements() 

(*not* getChildElements(), unless there's a corresponding change to
getChildAttributes())

Likewise, getChild() should be renamed getElement().

addChild(...) is already deprecated so it's not a problem, though I
actually believe addChild() is better than addContent() ("content"
implies "text content of this node" not "some sort of child of this
node")

getChildText(String name) is a convenience method anyway, but what
would be the problem with renaming it getText(String name) ?  The
presence of the parameter should clear up any ambiguity.

Then removeChild() / removeChildren() / setChildren() should be
removeElement() / removeElements() / setElements()

Following this logic, "getMixedContent()" should be renamed
"getChildren()" but that would be very confusing at this stage.  I'd
still vote +1 for it but it would cause a deluge of misguided bug
reports.

*That's* the proposal.  Not piecemeal, changing one name a dozen
times.  The whole kit and kaboodle.  We accept, once and for all, that
a child is not the same as an element.

Or not :-)

 - Alex


On Thu, Sep 14, 2000 at 05:49:52AM -0700, Alex Chaffee wrote:
> 
> Wasn't there a discussion a few months ago about renaming
> getChildren() to getElements()?  This Solomon-like solution was
> provided by somebody smart, I think James.
> 
> Recap:
> 
> element.getChildren()
> 	ambiguous; implies that it gets Attributes etc. :-(
> 
> element.getChildElements()
> 	too long to type :-(
> 
> element.getElements()
> 	brief; no way it can be misinterpreted :-)
> 
> Was this just forgotten, or was there a reason to keep getChildren
> that I missed?
> 
> (We could deprecate getChildren for a few months before the 1.0
> release to allow migration.)
> 
>  - Alex
> 
> P.S. This is orthogonal to the current "Element implements List"
> discussion.  BTW, I think it should not implement List, for this very
> reason: there is an ambiguity as to what the members of that list
> would be (elements or mixed or elements+attributes or ...)
> 
> 
> -- 
> Alex Chaffee                       mailto:alex@jguru.com
> jGuru - Java News and FAQs         http://www.jguru.com/alex/
> Creator of Gamelan                 http://www.gamelan.com/
> Founder of Purple Technology       http://www.purpletech.com/
> Curator of Stinky Art Collective   http://www.stinky.com/
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com

-- 
Alex Chaffee                       mailto:alex@jguru.com
jGuru - Java News and FAQs         http://www.jguru.com/alex/
Creator of Gamelan                 http://www.gamelan.com/
Founder of Purple Technology       http://www.purpletech.com/
Curator of Stinky Art Collective   http://www.stinky.com/

From bob at accurev.com  Fri Sep 15 19:02:50 2000
From: bob at accurev.com (bob)
Date: Fri Aug  6 17:04:58 2004
Subject: [jdom-interest] getChildren() vs getElements()
In-Reply-To: <20000915111639.H23172@edamame.stinky.com>
Message-ID: <Pine.LNX.3.96.1000915220126.12780H-100000@exeter.exeter.org>

> I think getChildElements() is too verbose and also redundant.  Of
> course it's a child element; what other kind of element would it
> return?  A parent element?  A cousin? :-)

Unspecified descendants?  (ie, dom's getElementByTagName() or whatever
doesn't do a shallow search, but rather a deep descendant-of-any-flavor
search.)

	-bob


From jhunter at collab.net  Fri Sep 15 19:34:31 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:04:58 2004
Subject: [jdom-interest] I just pulled down the latest source via WINCVS
References: <704ECFDA88B3D311B5F000A0C959E5B601FBE5@adobo.c2labs.com>
Message-ID: <39C2DC37.FB202106@collab.net>

> Yep, and packaging for distribution would typically not modify 
> repo files in place.

Exactly.  So we'll have this fixed shortly.

-jh-

From jhunter at collab.net  Fri Sep 15 19:54:11 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:04:58 2004
Subject: [jdom-interest] getChildren() vs getElements()
References: <20000914054952.G18335@edamame.stinky.com> <20000915111639.H23172@edamame.stinky.com>
Message-ID: <39C2E0D3.2CCA17EB@collab.net>

> getElements() is not ambiguous.  It doesn't imply that it recurses any
> more than getChildren() implies that it recurses.  Once you accept
> that an element can contain elements, it is not confusing (it only
> sounds self-referential, but it's not).

But element.getElement() -- the singular form -- does look way too
self-referential.

> getChildText(String name) is a convenience method anyway, but what
> would be the problem with renaming it getText(String name) ?  The
> presence of the parameter should clear up any ambiguity.

As much as I love the use of such a method, that's just awful.  You
don't change from parent text to child text retrieval based on a
parameter.

> Or not :-)

Yeah, I choose that one.  :-)

I like getChild() and getChildren() because it has a certain panache. 
Matches nicely with getParent().  Easy to tell them apart.  Nice and
short.  That naming makes me happy in a Zen sort of way.

-jh-

From pvg at c-c-s.com  Fri Sep 15 20:11:15 2000
From: pvg at c-c-s.com (Peter V. Gadjokov)
Date: Fri Aug  6 17:04:58 2004
Subject: [jdom-interest] getChildren() vs getElements()
Message-ID: <704ECFDA88B3D311B5F000A0C959E5B601FBE9@adobo.c2labs.com>


> Wait a second.  The +1s are coming fast and furious but...

You're right, I take mine back, this is more convoluted than I thought,
sorry for jumping the gun (I hadn't considered Jason's issue with the
convenience method and the points you raise below). 

> I think getChildElements() is too verbose and also redundant.  Of
> course it's a child element; what other kind of element would it
> return?  A parent element?  A cousin? :-)

Well, the parent is a possibility but then again, the parent can't be
anything but an element so getParent works fine there. I don't think
getChildElements is so long as to be 'too verbose', you are getting children
and they are elements. 
 
> getElements() is not ambiguous.  It doesn't imply that it recurses any
> more than getChildren() implies that it recurses.  Once you accept
> that an element can contain elements, it is not confusing (it only
> sounds self-referential, but it's not).

The recursion implication is not necessarily that clear - child for
'immediate descendant' and 'descendant' for everything else is pretty common
terminology. getChildElements is a decent hint there is no deep traversal. 
 
> The issue is terminological: there are many "children" of an element,
> but only some of them are elements.  Thus getElements() should return
> the children that are elements, getAttributes() should return the
> children that are attributes, and so forth.

I like this argument (even though Attributes are by definition leaves and
Elements do not have to be) - the naming is simple and consistent. 

> getChildren() should be renamed getElements() 
> 
> (*not* getChildElements(), unless there's a corresponding change to
> getChildAttributes())

I think I buy that (a tentative +1)

> Likewise, getChild() should be renamed getElement().

Same. 
 
> addChild(...) is already deprecated so it's not a problem, though I
> actually believe addChild() is better than addContent() ("content"
> implies "text content of this node" not "some sort of child of this
> node")

This sounds good too but I missed the discussions on that decision so it's
probably another discussion altogether. 
 
> getChildText(String name) is a convenience method anyway, but what
> would be the problem with renaming it getText(String name) ?  The
> presence of the parameter should clear up any ambiguity.

Hmm, this sounds a little iffier to me, name-overloading has its use but the
method name is already fairly terse and just adding a parameter doesn't
really make it that much clearer. But given the new shorter method names, is
the convenience method really needed? element.getElement("foo").getText();
doesn't seem so bad. Neither does something like ElemUtils.getText(Element
elem, String childName) - one can write oneself a personal class like that
if it never showed up in JDOM itself.  Jason, I imagine, would have a
stronger opinion on this. 

> Then removeChild() / removeChildren() / setChildren() should be
> removeElement() / removeElements() / setElements()

Another +1. 

> Following this logic, "getMixedContent()" should be renamed
> "getChildren()" but that would be very confusing at this stage.  I'd
> still vote +1 for it but it would cause a deluge of misguided bug
> reports.

So would I. And yes, it would create some extra noise on the list but
imagine having this debate again after a 1.0 release with a much larger
user-base. Picking a set of names that are clearly and defensibly consistent
is useful and most likely easier to achieve now than later. 
 
> *That's* the proposal.  Not piecemeal, changing one name a dozen
> times.  The whole kit and kaboodle.  We accept, once and for all, that
> a child is not the same as an element.

I'd be happy with all of the above - or any other proposal that is complete
and consistent. I think it would help the discussion if all proposals were
in the same vein - covering all the relevant methods and justifying the
choices. 

-pvg

From brett.mclaughlin at lutris.com  Fri Sep 15 20:39:35 2000
From: brett.mclaughlin at lutris.com (Brett McLaughlin)
Date: Fri Aug  6 17:04:58 2004
Subject: [jdom-interest] getChildren() vs getElements()
References: <20000914054952.G18335@edamame.stinky.com> <20000915111639.H23172@edamame.stinky.com> <39C2E0D3.2CCA17EB@collab.net>
Message-ID: <39C2EB77.F0FFA0CE@lutris.com>


Jason Hunter wrote:
> 
> > getElements() is not ambiguous.  It doesn't imply that it recurses any
> > more than getChildren() implies that it recurses.  Once you accept
> > that an element can contain elements, it is not confusing (it only
> > sounds self-referential, but it's not).
> 
> But element.getElement() -- the singular form -- does look way too
> self-referential.
> 
> > getChildText(String name) is a convenience method anyway, but what
> > would be the problem with renaming it getText(String name) ?  The
> > presence of the parameter should clear up any ambiguity.
> 
> As much as I love the use of such a method, that's just awful.  You
> don't change from parent text to child text retrieval based on a
> parameter.
> 
> > Or not :-)
> 
> Yeah, I choose that one.  :-)
> 
> I like getChild() and getChildren() because it has a certain panache.
> Matches nicely with getParent().  Easy to tell them apart.  Nice and
> short.  That naming makes me happy in a Zen sort of way.

Now, if it was only correct. But it isn't, and a cursory reading of any
XML specification makes it confusing, especially getChildren(), which no
amount of "looking at the return value" can solve. I admit that
getChildren() is easier - you should at least be willing to admit that
it's semantically incorrect with respect to XML ;-) Let's be fair here.

-Brett

> 
> -jh-
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org

From jhunter at collab.net  Fri Sep 15 20:47:32 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:04:58 2004
Subject: [jdom-interest] getChildren() vs getElements()
References: <704ECFDA88B3D311B5F000A0C959E5B601FBE9@adobo.c2labs.com>
Message-ID: <39C2ED54.FCD547C8@collab.net>

> > Wait a second.  The +1s are coming fast and furious but...
> 
> You're right, I take mine back, this is more convoluted than 
> I thought,

Ha, why do you think we postponed the decision?  :-)

> > (*not* getChildElements(), unless there's a corresponding change to
> > getChildAttributes())
> 
> I think I buy that (a tentative +1)

-50 on getChildAttributes().

> element.getElement("foo").getText();
> doesn't seem so bad. 

Except you're risking a NullPointerException.  That worked fine until
getChild() returned null if the child wasn't found.  You can read a long
email I wrote a couple months ago where I compared all the alternatives.

> Neither does something like ElemUtils.getText(Element
> elem, String childName) - one can write oneself a personal class 
> like that if it never showed up in JDOM itself.  

Except I want to include a cool JDOM example in my book.  And I'm not
about to use a personal class because what does that say about the API? 
It says it doesn't even solve a simple problem elegantly.

> Jason, I imagine, would have a stronger opinion on this.

There ya had it.  :-)

-jh-

From pvg at c-c-s.com  Fri Sep 15 21:18:27 2000
From: pvg at c-c-s.com (Peter V. Gadjokov)
Date: Fri Aug  6 17:04:58 2004
Subject: [jdom-interest] getChildren() vs getElements()
Message-ID: <704ECFDA88B3D311B5F000A0C959E5B601FBEA@adobo.c2labs.com>

 
> But element.getElement() -- the singular form -- does look way too
> self-referential.

It does but I think Alex is right - it's pretty hard to use JDOM and not
know that elements contain other elements. 

> > getChildText(String name) is a convenience method anyway, but what
> > would be the problem with renaming it getText(String name) ?  The
> > presence of the parameter should clear up any ambiguity.
> 
> As much as I love the use of such a method, that's just awful.  You
> don't change from parent text to child text retrieval based on a
> parameter.

That's a great reason to skip getText(String name). 


> I like getChild() and getChildren() because it has a certain panache. 
> Matches nicely with getParent().  Easy to tell them apart.  Nice and
> short.  That naming makes me happy in a Zen sort of way.

They are fine names. But they are a little contrary to typical terminology.
I think the fundamental issue is that a JDOM document tries to act as a tree
of nodes, without having a notion of generic nodes while treating Elements a
little differently. The reasoning is obvious and justifyable, most of the
time, you're traversing elements and element is the only non-leaf node type.
How about this alternative - A Document/Element describes a tree of
_elements_. Everything else is not really part of the tree (might be part of
the DOM tree, but JDOM is not DOM), everything else is just a property (or
property list) of an element. So, that means getChild/Children get to stay
since the refer to elements, always. The content thing goes away, a lot of
crazy PartialList magic goes away, things are stored explicitly in
containers appropriate for their type (gives you the option to go typesafe
when Java gets genericity), nothing other than an element is ever referred
to as a 'child'. So if you want to add comment, pi, you addPi, you
addComment, etc. What you lose - you lose the ability to represent
everything an element contains as a mutable list - why is this important
(I'm really asking, everthing I see in the implementation that gets the list
is always instanceof-ing it into components but there is likely a use I'm
not thinking of). If mutability is not important, a List of all sub-pieces
can be constructed on demand. You lose (at least, trivially, it can be
addressed) the ability to retain the exact location of the element text
among sub-elements. It is a lot simpler, though, conceptually. It does let
getChildText make sense. It even makes namespace declarations somewhat
clearer - namespace declarations apply to the descendants of an element
(which, attributes, in this universe, would not be). Now, before someone
points out this is not how XML (or at least DOM) is specified - yes, quite
true - but the current content/child/whatnot muddle doesn't seem much
closer. Did this approach, too, come up and and die a miserable death? The
array of messages on this topic in the archive is daunting.

-pvg


From jhunter at collab.net  Fri Sep 15 21:31:45 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:04:58 2004
Subject: [jdom-interest] getChildren() vs getElements()
References: <20000914054952.G18335@edamame.stinky.com> <20000915111639.H23172@edamame.stinky.com> <39C2E0D3.2CCA17EB@collab.net> <39C2EB77.F0FFA0CE@lutris.com>
Message-ID: <39C2F7B1.FC381822@collab.net>

> I admit that getChildren() is easier - you should at least be 
> willing to admit that it's semantically incorrect with respect to 
> XML ;-) Let's be fair here.

It's correct like how a digitally generated scene is correct.  
It's almost too correct.  It doesn't appeal to my humanity.

(Who says API design isn't an art.)

-jh-

From jhunter at collab.net  Fri Sep 15 21:33:55 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:04:58 2004
Subject: [jdom-interest] getChildren() vs getElements()
References: <704ECFDA88B3D311B5F000A0C959E5B601FBEA@adobo.c2labs.com>
Message-ID: <39C2F833.34F9DC3F@collab.net>

"Peter V. Gadjokov" wrote:
> The array of messages on this topic in the archive is daunting.

No less daunting than your single paragraph internal debates.  :-)

-jh-

From pvg at c-c-s.com  Fri Sep 15 21:50:53 2000
From: pvg at c-c-s.com (Peter V. Gadjokov)
Date: Fri Aug  6 17:04:58 2004
Subject: [jdom-interest] getChildren() vs getElements()
Message-ID: <704ECFDA88B3D311B5F000A0C959E5B601FBEB@adobo.c2labs.com>

> No less daunting than your single paragraph internal debates.  :-)
> 

Hey at least I'm not invoking Zen or the Quality-Without-A-Name :)

But point taken, I'll try to make my spewage more brief and structured. What
I was suggesting was  - 

- Move away from the 'tree-of-everything' model
- Adopt a 'tree-of-elements' model
- change the API to reflect this
	- children/parent stay and make sense and are about Elements
	- content (as a collection of everything
        in an element) becomes superfluous and is removed
- change the implementation to reflect this
	- less PartialList, more type-specific containers

That's all.

-pvg

From pvg at c-c-s.com  Sat Sep 16 01:59:07 2000
From: pvg at c-c-s.com (Peter V. Gadjokov)
Date: Fri Aug  6 17:04:58 2004
Subject: [jdom-interest] META: Children of a lesser spec
Message-ID: <704ECFDA88B3D311B5F000A0C959E5B601FBEC@adobo.c2labs.com>

>Now, if it was only correct. But it isn't, and a cursory reading of _any_
>XML specification makes it confusing, especially getChildren()...
  - Brett McLaughlin, during a JDOM API design discussion, emphasis mine

When we speak of spec conformance in the context of API design discussions,
what spec are we talking about? What spec, if any, _should_ we be talking
about? If we could settle this philosophical issue, some of the ongoing API
discussions could become somewhat clearer. 

So, to get this going, the classes of specification and my view of their
applicability: 

*] Core 'syntax-oriented' specs, e.g., The XML spec, the Namespace spec.

These specifications both define core features and their syntactical
representation in a well-formed, serialized XML document. Since a useful API
would do well to stay as syntax-independent as possible, I'd argue these
should not drive API-level decisions. Obviously, since they contain
information that goes beyond syntax, they should be consulted and taken into
serious consideration - the hard requirements of conformance, though, are
constrained to Builders and Outputers, not the core API. 

*] Other API specs, most notably DOM

Since one of the driving motivations behind JDOM is to be better (and not as
cumbersomeas ) than DOM, DOM should not be a significant driver of API
decisions. It should certainly serve as a source of ideas (both good and
bad) but familiarity with DOM and DOM-inspired expectations should be
secondary constraints during API design - the primary ones being usefulness,
clarity and elegance. 

*] Core 'syntax-independent' specs, e.g., the XML Infoset (any others?) 

These, I think, are a lot more relevant to in API discussions than the
previous ones. They describe XML documents and their components in terms of
logical structure as opposed to syntax (or serialization format). Such specs
should carry more weight in discussion than any other factor with the
exception of the ones directly related to creating a sensible, OO, Java API
- i.e. only the needs of API usefulness, clarity and elegance should
override the requirements of conceptual specs (e.g. JDOM could chose to hide
some of the conceptual complexity as mentioned in the JDOM philosophy FAQ).
In the appropriate places, the API design and usage documentation should
refer to concepts of such specs, describing how JDOM maps to and differs
from the concepts outlined in those specs. In a word, this is the task of
making the M in JDOM meaningful.

*] The JDOM spec

This mythical entity would be the result of the work described at the end of
the last item (and the ranting on mailing lists and the writing and using of
code, of course). We do want JDOM to grow up to become a standard, after all
- at the very least, it's worth agreeing to have or not to have one for 1.0.


Comments welcome. 

-pvg


From brett.mclaughlin at lutris.com  Sat Sep 16 03:46:27 2000
From: brett.mclaughlin at lutris.com (Brett McLaughlin)
Date: Fri Aug  6 17:04:58 2004
Subject: [jdom-interest] getChildren() vs getElements()
References: <704ECFDA88B3D311B5F000A0C959E5B601FBEB@adobo.c2labs.com>
Message-ID: <39C34F83.3DE08C94@lutris.com>


"Peter V. Gadjokov" wrote:
> 
> > No less daunting than your single paragraph internal debates.  :-)
> >
> 
> Hey at least I'm not invoking Zen or the Quality-Without-A-Name :)
> 
> But point taken, I'll try to make my spewage more brief and structured. What
> I was suggesting was  -
> 
> - Move away from the 'tree-of-everything' model
> - Adopt a 'tree-of-elements' model
> - change the API to reflect this
>         - children/parent stay and make sense and are about Elements
>         - content (as a collection of everything
>         in an element) becomes superfluous and is removed
> - change the implementation to reflect this
>         - less PartialList, more type-specific containers

Has ANYBODY other than Jason and I read the XML specification on this
list? I don't mean that any more sarcastically than you take it (;-)),
but come on. 
getChildAttributes() makes no sense, because an Element can only refer
to its own attributes. 

getChildElements makes perfect sense, because an Element can easily
refer to other elements than its own children.

addChild is horrible, because then getChild would have to return
elements, PIs, comments, etc.

addContent is correct, as the things you are adding are /clearly/
element content

Guys, I am not wed to the naming in the spec. But I am /strongly/
against calling something a "fish" when the spec says a "fish" is
something else entirely. I'd prefer everyone take a deep breath, stop
asking for things the way they want the spec to read, and read XML 1.0.
Then make your proposal, and clearly say when things are spec-deviant.

And I'll repeat - if it's a new name, that's considerable. But if the
spec clearly says a term is one thing, and you propose that term be used
to mean something /different/ than its use in the spec, that's a bad
idea, that's confusing, and I'll -1 it.

I'm all for ingenuity, but I'm not for convoluity (word?)

-Brett

> 
> That's all.
> 
> -pvg
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org

From brett.mclaughlin at lutris.com  Sat Sep 16 03:55:05 2000
From: brett.mclaughlin at lutris.com (Brett McLaughlin)
Date: Fri Aug  6 17:04:58 2004
Subject: [jdom-interest] META: Children of a lesser spec
References: <704ECFDA88B3D311B5F000A0C959E5B601FBEC@adobo.c2labs.com>
Message-ID: <39C35189.E2F0EB22@lutris.com>


"Peter V. Gadjokov" wrote:
> 
> >Now, if it was only correct. But it isn't, and a cursory reading of _any_
> >XML specification makes it confusing, especially getChildren()...
>   - Brett McLaughlin, during a JDOM API design discussion, emphasis mine
> 
> When we speak of spec conformance in the context of API design discussions,
> what spec are we talking about? What spec, if any, _should_ we be talking
> about? If we could settle this philosophical issue, some of the ongoing API
> discussions could become somewhat clearer.
> 
> So, to get this going, the classes of specification and my view of their
> applicability:
> 
> *] Core 'syntax-oriented' specs, e.g., The XML spec, the Namespace spec.
> 
> These specifications both define core features and their syntactical
> representation in a well-formed, serialized XML document. Since a useful API
> would do well to stay as syntax-independent as possible, I'd argue these
> should not drive API-level decisions. Obviously, since they contain

What? JDOM is an XML /model/ so how can we possibly ignore what XML says
about that model? If what JDOM represents is data that is defined by
this specification, how can we possibly not use this specification to
model that data? Otherwise, we wouldn't use the term Processing
Instruction, or XML Declaration, or Doctype. I don't buy this.

> information that goes beyond syntax, they should be consulted and taken into
> serious consideration - the hard requirements of conformance, though, are
> constrained to Builders and Outputers, not the core API.
> 
> *] Other API specs, most notably DOM
> 
> Since one of the driving motivations behind JDOM is to be better (and not as
> cumbersomeas ) than DOM, DOM should not be a significant driver of API
> decisions. It should certainly serve as a source of ideas (both good and
> bad) but familiarity with DOM and DOM-inspired expectations should be
> secondary constraints during API design - the primary ones being usefulness,
> clarity and elegance.

Agreed, 100%, on this one.

> 
> *] Core 'syntax-independent' specs, e.g., the XML Infoset (any others?)
> 
> These, I think, are a lot more relevant to in API discussions than the
> previous ones. They describe XML documents and their components in terms of
> logical structure as opposed to syntax (or serialization format). Such specs
> should carry more weight in discussion than any other factor with the
> exception of the ones directly related to creating a sensible, OO, Java API
> - i.e. only the needs of API usefulness, clarity and elegance should
> override the requirements of conceptual specs (e.g. JDOM could chose to hide
> some of the conceptual complexity as mentioned in the JDOM philosophy FAQ).
> In the appropriate places, the API design and usage documentation should
> refer to concepts of such specs, describing how JDOM maps to and differs
> from the concepts outlined in those specs. In a word, this is the task of
> making the M in JDOM meaningful.


M in JDOM doesn't mean anything ;-) Even on these grounds, you will find
that XML Infoset clearly defines content, and children. 

From amyzing at talsever.com  Sat Sep 16 04:14:44 2000
From: amyzing at talsever.com (Amy Lewis)
Date: Fri Aug  6 17:04:59 2004
Subject: [jdom-interest] getChildren() vs getElements()
In-Reply-To: <704ECFDA88B3D311B5F000A0C959E5B601FBEA@adobo.c2labs.com>; from pvg@c-c-s.com on Fri, Sep 15, 2000 at 09:18:27PM -0700
References: <704ECFDA88B3D311B5F000A0C959E5B601FBEA@adobo.c2labs.com>
Message-ID: <20000916071444.A21275@talsever.com>

On Fri, Sep 15, 2000 at 09:18:27PM -0700, Peter V. Gadjokov wrote:
[snip]
>How about this alternative - A Document/Element describes a tree of
>_elements_. Everything else is not really part of the tree (might be part of
>the DOM tree, but JDOM is not DOM), everything else is just a property (or
>property list) of an element. So, that means getChild/Children get to stay
>since the refer to elements, always. The content thing goes away, a lot of
>crazy PartialList magic goes away, things are stored explicitly in
>containers appropriate for their type (gives you the option to go typesafe
>when Java gets genericity), nothing other than an element is ever referred
>to as a 'child'. So if you want to add comment, pi, you addPi, you
>addComment, etc. What you lose - you lose the ability to represent
>everything an element contains as a mutable list - why is this important
>(I'm really asking, everthing I see in the implementation that gets the list
>is always instanceof-ing it into components but there is likely a use I'm
>not thinking of). If mutability is not important, a List of all sub-pieces
>can be constructed on demand. You lose (at least, trivially, it can be
>addressed) the ability to retain the exact location of the element text
>among sub-elements. It is a lot simpler, though, conceptually. It does let

More than that, you lose any sense of relative location for all the
child nodes, between nodes of different types.  If you happen to have
an enormous (badly designed) element that contains two PIs, thirty
comments, and seventy element children, you've lost the ability to
associate the comments with the siblings that they pair with (which is
pretty much the way that comments generally work, even though in a tree
model they "belong" to the mutual parent of the thing that they're
commenting on).  To take an example from html/xhtml, you've changed
"This is <em>important</em>, please take note!" to "This is, please
take note!<em>important</em>" or <em>important</em>This is, please take
note!".  While the latter has a certain Yoda-like charm, it isn't at
all accurate.  The two PIs, which (let us say) represent page breaks,
have now moved to the top (or bottom?  Or some other "standard"
location that has nothing to do with their actual placement in the
document?) where they live happily together spewing out blank sheets,
while the rest of the text runs on and on, like this paragraph.

So, somewhere, somehow, in the API, you have to *preserve* document
order.  You have to preserve among children of unlike type (and unlike
others here, I tend to think of "child" in the more XPath-y sense of
"everything except the attributes and namespaces").  If you lose
document order, you prolly ought to just not support comments and PIs,
and you ought to warn folks not to expect mixed content to work in any
complex context, since you've lost the original relative positions of
the content.

So, while from a programming sense it is certainly *cleaner* to
describe a tree of elements, it doesn't usefully describe the documents
that the programmers are going to encounter, and isn't, therefore, a
good abstraction.

Amy!
-- 
Amelia A. Lewis          alicorn@mindspring.com          amyzing@talsever.com
There are two major products that came out of Berkeley: LSD and BSD Unix.
We don't believe this to be a coincidence.

From pvg at c-c-s.com  Sat Sep 16 05:10:59 2000
From: pvg at c-c-s.com (Peter V. Gadjokov)
Date: Fri Aug  6 17:04:59 2004
Subject: [jdom-interest] getChildren() vs getElements()
Message-ID: <704ECFDA88B3D311B5F000A0C959E5B601FBED@adobo.c2labs.com>

Amy Lewis wrote:

> More than that, you lose any sense of relative location for all the
> child nodes, between nodes of different types. [...]
> So, while from a programming sense it is certainly *cleaner* to
> describe a tree of elements, it doesn't usefully describe the 
> documents that the programmers are going to encounter, and isn't, 
> therefore, a good abstraction.

"It's worse than that - he's dead, Jim!"

You're absolutely right, losing the document for non-elements won't cut it.
But is it really the case that the abstraction itself is bad? If I hadn't
stuffed my foot in my mouth by talking about implementation details in an
API design discussion, the abstraction described is essentially identical to
what we have now. Children are always elements. Everything else is something
else. To get the ordered-document-of-everything view, you use the List
accessors (the thing JDOM now calls content), to get the Element-centric
view, you use getChild/getChildren.  Granted, this isn't what the XML
Infoset calls children. The argument  for giving Elements the simple,
easy-to-use, Zen-compliant method names is based on the assumption that
Element-centric traversal of programmatically generated XML documents is
becoming as important and common a use-case as processing human-written,
document-annotation-style XML. Some (like Don Box and co) go as far as to
argue that the latter is going to eventually die out [1]. Is this worth
using terminology that is simple, evokes the sound of one hand clapping but
is not 'spec-compliant'? I think so, but I'm biased, living largely in the
XML-as-RPC, element-centric, PI/Comment devoid world. 

"...a tedious argument of insidious intent to lead you to an overwhelming
question..." 

The two viable (i.e. consistent) approaches so far seem to be Alex's
proposal (call Elements elements and children children and possibly make
Jason live with something like getChildElementText[Trim]) and keeping things
(API-wise) as they are. I'd be happy with either as long as the change (if
any) is not piecemeal. 

-pvg

[1] _Essential XML : Beyond MarkUp_; Don Box, Aaron Skonnard, John Lam;
Addison-Wesley, 2000; ISBN: 0201709147 
 


From pvg at c-c-s.com  Sat Sep 16 06:04:32 2000
From: pvg at c-c-s.com (Peter V. Gadjokov)
Date: Fri Aug  6 17:04:59 2004
Subject: [jdom-interest] serialVersionUID
Message-ID: <704ECFDA88B3D311B5F000A0C959E5B601FBEE@adobo.c2labs.com>

I've made a pass at implementing this (long-term persistence support). I'll
put up the modified files when I'm done but since I promised numbers here
are my first set of informal numbers for parsing - 

The results are from in-memory parsing/deserializing, times are averaged
over multiple runs, all times are in elapsed seconds, all sizes in bytes.
The platform is a dual CelA 500 running Win2kPro and JDK 1.3.0 with client
side Hotspot. I used OptimizeIt 4.0 to look for bottlenecks but the results
listed are in elapsed time deltas from System.currentTimeMillis. 

Tiny document - 

Size as XML: 1247
Size as ser: 2832
Number of runs: 1000

SAXBuilder parse elapsed time: 5.56
Deserialization elapsed time : 3.20

SAXBuilder parses/sec: 180.00
Deserializations/sec : 312.21

So, the document ends up being a significantly bigger but the speed is also
greatly improved.

Huge document - 

Size as XML: 865612
Size as ser: 1068366
Number of runs: 40

SAXBuilder parse elapsed time: 47.67
Deserialization elapsed time : 47.62

SAXBuilder parses/sec: 0.84
Deserializations/sec : 0.84

In other words, same deal but bigger. There is no easy way to re-use the
allocated memory so I think both are getting i/o limited as the system
starts paging (as it does as the java process image grows, even when given
128 megs of heap on a machine of with half a gig of RAM). I think I can
change my test harness to alleviate or eliminate the effect. More on that
later. 

These runs were done with a couple of optimizations I made to Namespace.
Without them, deserialization is a bit slower than parsing in the huge file
case. 

Anyhow, that's the lot for now. Write results, the benchmark set and the
patch should be available today or tomorrow (I haven't had a chance to do
any significant testing). Custom read/write methods were added to the
following classes: 

M Attribute.java
M CDATA.java
M Comment.java
M DocType.java
M Document.java
M Element.java
M Entity.java
M ProcessingInstruction.java

If I've missed something, please yell. Any suggestions for documents to use
in performance testing would be much appreciated. 

-pvg



From pvg at c-c-s.com  Sat Sep 16 06:50:34 2000
From: pvg at c-c-s.com (Peter V. Gadjokov)
Date: Fri Aug  6 17:04:59 2004
Subject: [jdom-interest] getChildren() vs getElements()
Message-ID: <704ECFDA88B3D311B5F000A0C959E5B601FBEF@adobo.c2labs.com>

Amy Lewis wrote:

> More than that, you lose any sense of relative location for all the
> child nodes, between nodes of different types. [...]
> So, while from a programming sense it is certainly *cleaner* to
> describe a tree of elements, it doesn't usefully describe the 
> documents that the programmers are going to encounter, and isn't, 
> therefore, a good abstraction.

"It's worse than that - he's dead, Jim!"

You're absolutely right, losing the document for non-elements won't cut it.
But is it really the case that the abstraction itself is bad? If I hadn't
stuffed my foot in my mouth by talking about implementation details in an
API design discussion, the abstraction described is essentially identical to
what we have now. Children are always elements. Everything else is something
else. To get the ordered-document-of-everything view, you use the List
accessors (the thing JDOM now calls content), to get the Element-centric
view, you use getChild/getChildren.  Granted, this isn't what the XML
Infoset calls children. The argument  for giving Elements the simple,
easy-to-use, Zen-compliant method names is based on the assumption that
Element-centric traversal of programmatically generated XML documents is
becoming as important and common a use-case as processing human-written,
document-annotation-style XML. Some (like Don Box and co) go as far as to
argue that the latter is going to eventually die out [1]. Is this worth
using terminology that is simple, evokes the sound of one hand clapping but
is not 'spec-compliant'? I think so, but I'm biased, living largely in the
XML-as-RPC, element-centric, PI/Comment devoid world. 

"...a tedious argument of insidious intent to lead you to an overwhelming
question..." 

The two viable (i.e. consistent) approaches so far seem to be Alex's
proposal (call Elements elements and children children and possibly make
Jason live with something like getChildElementText[Trim]) and keeping things
(API-wise) as they are. I'd be happy with either as long as the change (if
any) is not piecemeal. 

-pvg

[1] _Essential XML : Beyond MarkUp_; Don Box, Aaron Skonnard, John Lam;
Addison-Wesley, 2000; ISBN: 0201709147 
 

From pvg at c-c-s.com  Sat Sep 16 07:29:58 2000
From: pvg at c-c-s.com (Peter V. Gadjokov)
Date: Fri Aug  6 17:04:59 2004
Subject: [jdom-interest] getChildren() vs getElements()
Message-ID: <704ECFDA88B3D311B5F000A0C959E5B601FBF0@adobo.c2labs.com>


> Has ANYBODY other than Jason and I read the XML specification on this
> list? I don't mean that any more sarcastically than you take it (;-))

I've read it, but I'll be the first to admit I have a lot more experience
designing and implementing OO APIs than I do dealing with XML. So it's not
hard for me to read the spec and still miss something - that's changing, in
no small part thanks to input from the list. In the interim, you're forced
to read my harebrained ideas (and I don't mean that any more sarcastically
than you take it :)

> getChildAttributes() makes no sense, because an Element can only refer
> to its own attributes. 

Must have been someone else's proposal, it isn't in anything above. I was
talking about sticking with getChild/Children for elements and ditching
content/losing global doc. order. The latter, as Amy Lewis pointed out, is
completely bogus. 

Actually, I went back and re-read the last set of emails and noticed
getChildAttributes in Alex's proposal and my badly quoted +1 -
getChildAttributes is undoubtedly wrong, under any spec. No spec describes
an attribute as a child. This also explains Jason's -50. My mistake, I
quoted more than I meant to above my +1. 

> getChildElements makes perfect sense, because an Element can easily
> refer to other elements than its own children.
> 
> addChild is horrible, because then getChild would have to return
> elements, PIs, comments, etc.
> 
> addContent is correct, as the things you are adding are /clearly/
> element content

Under this scheme, we'd stay with getChild[ren] - we stay with using the
term 'child' for elements exclusively. getChildElements is not needed in
that case, addChild would be for Elements only, gives you symmetry with
getChild. As to addContent, I think it's not so cut and dry - what the XML
spec calls content, the Infoset calls the 'children property'. The Infoset
does use (but not define) the term content to mean the same thing but the
explicit property is 'children'. 

> Guys, I am not wed to the naming in the spec. But I am /strongly/
> against calling something a "fish" when the spec says a "fish" is
> something else entirely. I'd prefer everyone take a deep breath, stop
> asking for things the way they want the spec to read, and 
> read XML 1.0.
> Then make your proposal, and clearly say when things are spec-deviant.

The current use of getChild is infoset-deviant. I'm fine with most of Alex's
proposal which is different from what we have now but almost completely
infoset compliant. I'm also fine with the the way things are now, perhaps
with the addition of addChild convenience methods (passthrough to
addContent(Element el) that would make the naming symmetrical. As to
getChildElement[s], for all I know, I'm fine with it too. But it would be
nice to see a brief writeup of all relevant methods under that naming scheme
or a reference to a list-archive message that contains it. Alex's point is a
very good one - it's far too confusing to be talking about single method
names. 

> And I'll repeat - if it's a new name, that's considerable. But if the
> spec clearly says a term is one thing, and you propose that 
> term be used
> to mean something /different/ than its use in the spec, that's a bad
> idea, that's confusing, and I'll -1 it.

Agreed. But the interpretation of the spec (and which spec) is what prompted
my other thread. The specs are getting so big and plentiful, chances are
something will be confusing under some spec. 
 
> I'm all for ingenuity, but I'm not for convoluity (word?)

pvg@triptonite:~ jargon convoluity
No matches for "convoluity" at
<http://work.ucsd.edu:5141/cgi-bin/http_webster>
pvg@triptonite:~ webster convoluity
No matches for "convoluity" at <http://www.m-w.com>
No matches for "convoluity" at
<http://work.ucsd.edu:5141/cgi-bin/http_webster> 

But in the spirit of ingenuity, let's declare it a word. 

-pvg

From pvg at c-c-s.com  Sat Sep 16 08:32:04 2000
From: pvg at c-c-s.com (Peter V. Gadjokov)
Date: Fri Aug  6 17:04:59 2004
Subject: [jdom-interest] META: Children of a lesser spec
Message-ID: <704ECFDA88B3D311B5F000A0C959E5B601FBF1@adobo.c2labs.com>

> What? JDOM is an XML /model/ so how can we possibly ignore 
> what XML says
> about that model? If what JDOM represents is data that is defined by
> this specification, how can we possibly not use this specification to
> model that data? Otherwise, we wouldn't use the term Processing
> Instruction, or XML Declaration, or Doctype. I don't buy this.

I think you may have misunderstood what I wrote. It's a model allright. And
anything these specs say about the model is relevant. They also say an awful
lot about syntax, which is not as relevant - unless it's very closely tied
to the model and you can't hide it. Specs that are specifically and only
about models should be allowed to override whatever syntax specs say about
models. Good API design should be allowed to override whatever any spec says
about model - that is, it should be allowed to represent a different model,
as long as it makes for a better API and is deterministically, and
bidirectionally mappable to the specified model. I didn't say ignore, I said
'not drive API design'. Whatever the API design it must be capable of,
directly or otherwise, expressing the entirety of the core XML model,
whatever spec it is defined in. The syntax stuff, though, should live in
Builders and Outputers, as far as humanly possible. [*]

> M in JDOM doesn't mean anything ;-) 

Waiddaminute, you just said it was a /model/ :) It does mean something, it
must necessarily be a model that is equivalent to (or a mappable superset
of) what the specs talk about AND something that makes sense in Java. For
instance, the entire notion of 'Node' is pretty much a DOM thing - nothing
in, say, the infoset talks about Nodes yet the infoset explicitly states
that DOM is considered infoset compliant. No, I'm not saying lets add Nodes
- but something like JDOM is necessarily a model, potentially a model that
extends/transforms the less expressive models it covers - Java is a far more
expressive model than anything in XML and I think we're in agreement that we
should make use of that, even if we don't have consensus on _how_. 

> Even on these grounds, you will find
> that XML Infoset clearly defines content, and children. 
>

It defines children and occasionally uses the term content, without
specification. The term content comes from the XML spec (a mostly-syntax
spec). Terms defined in other specs are cross-referenced from infoset to
other specs, oddly enough, content is not. That may be intentional or a bug
in the spec, I have no idea - fact is, content is not solidly defined
terminology in Infoset world - the term 'children' is. 

> This simply could not be any clearer - getChild() and  getChildren() are
> absolutely wrong according to this. So again, we are back to either:
> getElement()/getElements()
> or
> getChildElement()/getChildElements()

Yes they are wrong, no argument. They are also better API names. So what's
more important, exact compliance with the spec naming or intuitive element
traversal method names? Perhaps that's the thing we disagree on - I don't
see any of the answers as exceptionally obvious. But some seem more
consistent than others to me. 

> And again, the second is much clearer, particularly when XPath comes
> into play.

Taking getChildElement/getChildElements and going with the infoset
terminology means replacing getContent/addContent and co with
getChildren/addChild. If child is to mean something other than element then
by your own argument (which I agree with) it should mean what it means in
the spec. And nothing is more explicit about what 'child' means than the
infoset. [**]

> It is good to define what specs we should look at. It's also worth 
> noting that even if we disagree on the XML and Namespace spec as 
> being key, the Infoset spec alone has plenty to say on our names.

It certainly does. I may have made a mistake in using the word 'children' in
the subject - I really meant to start a meta-discussion about what specs
should drive core API design. I still stand by:
 Java/OO API considerations/JDOM >= Infoset >= Syntax specs

But I don't mean to imply that '>=' means 'can ignore'. Every time  >= is
not actually an =, it must be done with complete certainty that the
extension is beneficial and allows for a deterministic, clear bidirectional
mapping between he concepts of the superset to those of the subset.

-pvg

[*] This was the gist of my namespace-prefix rant - I thought (and still
think) namespace prefixen can be made a lot less prominent (as they should
be, since they are very much a syntactic feature) in the core API without
compromising the ability to control and use them. The current implementation
is wrong by omission - it does not distinguish between namespace (or
namespace name, in infoset terminology) and namespace declaration. I'll try
to write it up briefly, with XML spec/Infoset terminology and in terms of an
API, in the hopes that it will be more digestible than an 8-page
single-paragraph text overview. 

[**] Incidentally, if we were to become Infoset hardasses, DocType is
apparently a  child of document, unlike the JDOM implementation. 

From pvg at c-c-s.com  Sat Sep 16 08:33:27 2000
From: pvg at c-c-s.com (Peter V. Gadjokov)
Date: Fri Aug  6 17:04:59 2004
Subject: [jdom-interest] getChildren() vs getElements()
Message-ID: <704ECFDA88B3D311B5F000A0C959E5B601FBF2@adobo.c2labs.com>

I wrote: 

> You're absolutely right, losing the document for non-elements 
> won't cut it.

In case it wasn't clear, this was supposed to be 'losing the document
order'. 

-pvg

From amyzing at talsever.com  Sat Sep 16 09:27:09 2000
From: amyzing at talsever.com (Amy Lewis)
Date: Fri Aug  6 17:04:59 2004
Subject: [jdom-interest] A plea for the orphans
Message-ID: <20000916122709.A21612@talsever.com>

Hmmm.

While we're on the topic of children, I'd like to request a change to
the API.

I'd like to see Attribute, Comment, Processing Instruction, and
possible Entity contain a member, Element parent, with getParent() (but
possibly no setParent(); I'm not convinced we need it entirely).  This
would require that the builders set the parent attribute, and would
require that the changing of content also perform a verification step
(which is potentially expensive).

I'd like to see this, because I want better navigation.  It isn't
necessary to get as complex as DOM, but without the ability to move
upward in the tree (downward is usually possible), then any attempt to
implement a TreeIterator (seems to me the basic element for
navigability) requires saving a truly inordinate amount of state on the
way.

Elements have parents.  Was there a particular reason that the other
children (umm, and attributes, too, since they're not considered
children) don't have parents (matter of fact, attributes are
specifically noted as having parents in XPath, even though they aren't
children).

Amy!
-- 
Amelia A. Lewis          alicorn@mindspring.com          amyzing@talsever.com
Did you exchange a walk-on part in the war for the lead role in a cage?
		-- Pink Floyd

From brett.mclaughlin at lutris.com  Sat Sep 16 13:19:22 2000
From: brett.mclaughlin at lutris.com (Brett McLaughlin)
Date: Fri Aug  6 17:04:59 2004
Subject: [jdom-interest] META: Children of a lesser spec
References: <704ECFDA88B3D311B5F000A0C959E5B601FBF1@adobo.c2labs.com>
Message-ID: <39C3D5CA.58BCFF9C@lutris.com>


"Peter V. Gadjokov" wrote:
> 
> > What? JDOM is an XML /model/ so how can we possibly ignore
> > what XML says
> > about that model? If what JDOM represents is data that is defined by
> > this specification, how can we possibly not use this specification to
> > model that data? Otherwise, we wouldn't use the term Processing
> > Instruction, or XML Declaration, or Doctype. I don't buy this.
> 
> I think you may have misunderstood what I wrote. It's a model allright. And
> anything these specs say about the model is relevant. They also say an awful
> lot about syntax, which is not as relevant - unless it's very closely tied
> to the model and you can't hide it. Specs that are specifically and only
> about models should be allowed to override whatever syntax specs say about
> models. Good API design should be allowed to override whatever any spec says
> about model - that is, it should be allowed to represent a different model,
> as long as it makes for a better API and is deterministically, and
> bidirectionally mappable to the specified model. I didn't say ignore, I said
> 'not drive API design'. Whatever the API design it must be capable of,
> directly or otherwise, expressing the entirety of the core XML model,
> whatever spec it is defined in. The syntax stuff, though, should live in
> Builders and Outputers, as far as humanly possible. [*]
> 
> > M in JDOM doesn't mean anything ;-)
> 
> Waiddaminute, you just said it was a /model/ :) It does mean something, it
> must necessarily be a model that is equivalent to (or a mappable superset
> of) what the specs talk about AND something that makes sense in Java. For
> instance, the entire notion of 'Node' is pretty much a DOM thing - nothing
> in, say, the infoset talks about Nodes yet the infoset explicitly states
> that DOM is considered infoset compliant. No, I'm not saying lets add Nodes
> - but something like JDOM is necessarily a model, potentially a model that
> extends/transforms the less expressive models it covers - Java is a far more
> expressive model than anything in XML and I think we're in agreement that we
> should make use of that, even if we don't have consensus on _how_.

You missed the joke - JDOM used to be an acronym, where 'M' stood for
Model. JDOM is no longer an acronym, so the 'M' doesn't mean anything.
Sorry ;-) 

> 
> > Even on these grounds, you will find
> > that XML Infoset clearly defines content, and children.
> >
> 
> It defines children and occasionally uses the term content, without
> specification. The term content comes from the XML spec (a mostly-syntax
> spec). Terms defined in other specs are cross-referenced from infoset to
> other specs, oddly enough, content is not. That may be intentional or a bug
> in the spec, I have no idea - fact is, content is not solidly defined
> terminology in Infoset world - the term 'children' is.
> 
> > This simply could not be any clearer - getChild() and  getChildren() are
> > absolutely wrong according to this. So again, we are back to either:
> > getElement()/getElements()
> > or
> > getChildElement()/getChildElements()
> 
> Yes they are wrong, no argument. They are also better API names. So what's
> more important, exact compliance with the spec naming or intuitive element
> traversal method names? Perhaps that's the thing we disagree on - I don't
> see any of the answers as exceptionally obvious. But some seem more
> consistent than others to me.

Whoa - you built a straw man. There is a difference betwwn intuitive
element traversal method names, and intuitive element traversal method
names /that overlap names of other things/. We aren't talking about
being intuitive or not; if that was the only concern, I'd +1 getChild().
But we're talking about intuitive, at the cost of being incorrect with
the spec. In that case, I'm firmly -1.

-Brett

> 
> > And again, the second is much clearer, particularly when XPath comes
> > into play.
> 
> Taking getChildElement/getChildElements and going with the infoset
> terminology means replacing getContent/addContent and co with
> getChildren/addChild. If child is to mean something other than element then
> by your own argument (which I agree with) it should mean what it means in
> the spec. And nothing is more explicit about what 'child' means than the
> infoset. [**]
> 
> > It is good to define what specs we should look at. It's also worth
> > noting that even if we disagree on the XML and Namespace spec as
> > being key, the Infoset spec alone has plenty to say on our names.
> 
> It certainly does. I may have made a mistake in using the word 'children' in
> the subject - I really meant to start a meta-discussion about what specs
> should drive core API design. I still stand by:
>  Java/OO API considerations/JDOM >= Infoset >= Syntax specs
> 
> But I don't mean to imply that '>=' means 'can ignore'. Every time  >= is
> not actually an =, it must be done with complete certainty that the
> extension is beneficial and allows for a deterministic, clear bidirectional
> mapping between he concepts of the superset to those of the subset.
> 
> -pvg
> 
> [*] This was the gist of my namespace-prefix rant - I thought (and still
> think) namespace prefixen can be made a lot less prominent (as they should
> be, since they are very much a syntactic feature) in the core API without
> compromising the ability to control and use them. The current implementation
> is wrong by omission - it does not distinguish between namespace (or
> namespace name, in infoset terminology) and namespace declaration. I'll try
> to write it up briefly, with XML spec/Infoset terminology and in terms of an
> API, in the hopes that it will be more digestible than an 8-page
> single-paragraph text overview.
> 
> [**] Incidentally, if we were to become Infoset hardasses, DocType is
> apparently a  child of document, unlike the JDOM implementation.
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org

From jhunter at collab.net  Sat Sep 16 14:13:11 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:04:59 2004
Subject: [jdom-interest] A plea for the orphans
References: <20000916122709.A21612@talsever.com>
Message-ID: <39C3E267.3E9F9D00@collab.net>

> I'd like to see Attribute, Comment, Processing Instruction, and
> possible Entity contain a member, Element parent, with getParent() 

This was proposed before by Bob to support XPath.  I seem to recall he
had started to work on implementing it.  I could dig the archives, but
it's Saturday and phooey.  :-)

A problem with this is that our String representation of text can't have
a getParent() and that's a bit unfortunate but not (imho) unfortunate
enough to switch to having a Text class.

-jh-

From amyzing at talsever.com  Sat Sep 16 16:47:23 2000
From: amyzing at talsever.com (Amy Lewis)
Date: Fri Aug  6 17:04:59 2004
Subject: [jdom-interest] A plea for the orphans
In-Reply-To: <39C3E267.3E9F9D00@collab.net>; from jhunter@collab.net on Sat, Sep 16, 2000 at 02:13:11PM -0700
References: <20000916122709.A21612@talsever.com> <39C3E267.3E9F9D00@collab.net>
Message-ID: <20000916194723.A22473@talsever.com>

On Sat, Sep 16, 2000 at 02:13:11PM -0700, Jason Hunter wrote:
>> I'd like to see Attribute, Comment, Processing Instruction, and
>> possible Entity contain a member, Element parent, with getParent() 
>
>This was proposed before by Bob to support XPath.  I seem to recall he
>had started to work on implementing it.  I could dig the archives, but
>it's Saturday and phooey.  :-)

There's a partial, in-progress XPath engine in CVS (contribs).

>A problem with this is that our String representation of text can't have
>a getParent() and that's a bit unfortunate but not (imho) unfortunate
>enough to switch to having a Text class.

True, but not relevant.  Having to externally store state when dealing
with text (which is a pain to deal with anyway, due to white space
issues) is clearly going to be the problem of the implementor of any
navigational add on (I know; I'm also in process on something that
isn't quite XPath).  Neither is getParent() absolutely required.  It's
just that, for navigation, if the things that *are* defined within the
API have some notion of their ancestry, life is significantly simpler.

The XML tree model demands that the implementation of navigability
treat a number of things as special cases--like the fact that
attributes *have* parents, but are *not* children.  I can think of
reasons not to store parentage inside each thing where we can do so
(performance reasons, primarily--it's just a lot simpler to have
one-way links; maintenance of double links is harder, which means it
requires more bullet-proofing, which costs, and it still is likely to
break more often than single linkage), and am willing to accept those
sorts of arguments (for folks that don't need that behavior, the price
may be too high), but the fact that it can't be made consistent 'cause
String is final doesn't much move me.

Less work for me (or those who need this functionality) isn't
necessarily a compelling argument, if it means on average worse results
for a majority of users.  But I'd like hear that, if that's the case. 
Or other reasons, perhaps?

Amy!
-- 
Amelia A. Lewis          alicorn@mindspring.com          amyzing@talsever.com
Do you ever feel like putting your fist through a window just so you can
feel something?

From elharo at metalab.unc.edu  Sun Sep 17 04:59:23 2000
From: elharo at metalab.unc.edu (Elliotte Rusty Harold)
Date: Fri Aug  6 17:04:59 2004
Subject: [jdom-interest] A plea for the orphans
In-Reply-To: <39C3E267.3E9F9D00@collab.net>
References: <20000916122709.A21612@talsever.com>
 <39C3E267.3E9F9D00@collab.net>
Message-ID: <p04330100b5ea620edb05@[168.100.203.234]>

At 2:13 PM -0700 9/16/00, Jason Hunter wrote:

>A problem with this is that our String representation of text can't have
>a getParent() and that's a bit unfortunate but not (imho) unfortunate
>enough to switch to having a Text class.
>

How about if I tossed in that it would eliminate the need for a CDATA 
class since a Text class could easily have an isCDATA property with 
appropriate getter and setter methods? Then we'd be adding one class 
and removing one. Is that fortunate enough to switch you?

-- 

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
|                  The XML Bible (IDG Books, 1999)                   |
|              http://metalab.unc.edu/xml/books/bible/               |
|   http://www.amazon.com/exec/obidos/ISBN=0764532367/cafeaulaitA/   |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://metalab.unc.edu/javafaq/ |
|  Read Cafe con Leche for XML News: http://metalab.unc.edu/xml/     |
+----------------------------------+---------------------------------+

From avandelft at epo.org  Mon Sep 18 01:22:28 2000
From: avandelft at epo.org (Andre Van Delft)
Date: Fri Aug  6 17:04:59 2004
Subject: [jdom-interest] getChildren() vs getElements()
References: <704ECFDA88B3D311B5F000A0C959E5B601FBEB@adobo.c2labs.com>
Message-ID: <39C5D0C4.2426A77F@epo.org>

"Peter V. Gadjokov" wrote:

> But point taken, I'll try to make my spewage more brief and structured. What
> I was suggesting was  -
>
> - Move away from the 'tree-of-everything' model
> - Adopt a 'tree-of-elements' model
> - change the API to reflect this
>         - children/parent stay and make sense and are about Elements
>         - content (as a collection of everything
>         in an element) becomes superfluous and is removed
> - change the implementation to reflect this
>         - less PartialList, more type-specific containers

But should addChild then stay? I quote from my posting of July 21:


> I find the name getChildren misleading.
>
> When I do an addChild(String), I would expect this to
> influence the result of a call to getChildren(). It does not.
> I propose to replace the name by getChildElements().
> Alternatively addChild(String) could be renamed addString(String).
>





-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://jdom.org/pipermail/jdom-interest/attachments/20000918/25a2d920/attachment.htm
From mbreig at i2ag.de  Mon Sep 18 05:24:47 2000
From: mbreig at i2ag.de (Marcus Breig)
Date: Fri Aug  6 17:04:59 2004
Subject: [jdom-interest] DTD im XML-File and Element.getContent()
Message-ID: <39C6098E.5B70447F@i2ag.de>

Hi all,

I am new in using JDOM for parsing XML-files.

My problem: my sample XML-File contains a DTD for
defining my XML-language. In this case the method
Element.getContent() always returns an empty string.

If the DTD is not in the file everything is OK.

I have tested this "feature" also with the pretty-printer
example from the JDOM indroduction from the
jdom-homepage. The same effect!

Is this a known problem? Should I read the manual? ;-)

thanks in advance

Marcus


From brett.mclaughlin at lutris.com  Mon Sep 18 07:23:33 2000
From: brett.mclaughlin at lutris.com (Brett McLaughlin)
Date: Fri Aug  6 17:04:59 2004
Subject: [jdom-interest] DTD im XML-File and Element.getContent()
References: <39C6098E.5B70447F@i2ag.de>
Message-ID: <39C62565.2575F21A@lutris.com>


Marcus Breig wrote:
> 
> Hi all,
> 
> I am new in using JDOM for parsing XML-files.
> 
> My problem: my sample XML-File contains a DTD for
> defining my XML-language. In this case the method
> Element.getContent() always returns an empty string.
> 
> If the DTD is not in the file everything is OK.
> 
> I have tested this "feature" also with the pretty-printer
> example from the JDOM indroduction from the
> jdom-homepage. The same effect!
> 
> Is this a known problem? Should I read the manual? ;-)

Can you post your XML document? I think I know what this is, but I want
to make sure.

Thanks
Brett

> 
> thanks in advance
> 
> Marcus
> 
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org

From VanDoorenD at icfg.com  Mon Sep 18 08:43:32 2000
From: VanDoorenD at icfg.com (Van Dooren, Damian)
Date: Fri Aug  6 17:04:59 2004
Subject: [jdom-interest] Off Topic - XSL (Xalan) question
Message-ID: <9DA96145A87BD411BDAE0008C7A49B640117C9@mail.icfg.com>

I know this question is not directly related to JDom and for that I
apologize, but I know someone here will have the answer I need.

I'm using JDom to create XML that I then process with XSL via Xalan. My XSL
is very simple I'm not even adding any of the XML data to it yet. I have an
<a> tag that the Xalan is dying on. This is the error I get:

org.apache.xalan.xslt.XSLProcessorException: The reference to entity
"subaction"  must end with the ';' delimiter.

This is the line it is dying on:

<a
href='http://localhost/login/ActionServer?action=loadpage&subaction=html&fil
eName=client-inquiry.html'>Client Inquiry</a>

I've included the XSL and have commented out the offending line. If someone
could point out what I've done wrong I would greatly appreciated it.

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
                version="1.0"
>  
  <xsl:template match="/">
    <html>
      <head><title>Main Menu</title></head>
      
      <body bgcolor="#FFFFFF">
        <h2>Main Menu</h2>
        <p>
<!-- Why doesn't it like this line?
        <a
href='http://localhost/login/ActionServer?action=loadpage&subaction=html&fil
eName=client-inquiry.html'>Client Inquiry</a>
-->
        </p>
      </body>
    </html>
  </xsl:template>
</xsl:stylesheet>


-----
Damian Van Dooren
Information Technology
The Investment Centre
(519) 672-4389 x718
 

From brett.mclaughlin at lutris.com  Mon Sep 18 09:24:33 2000
From: brett.mclaughlin at lutris.com (Brett McLaughlin)
Date: Fri Aug  6 17:04:59 2004
Subject: [jdom-interest] Off Topic - XSL (Xalan) question
References: <9DA96145A87BD411BDAE0008C7A49B640117C9@mail.icfg.com>
Message-ID: <39C641C1.F81E9C29@lutris.com>


"Van Dooren, Damian" wrote:
> 
> I know this question is not directly related to JDom and for that I
> apologize, but I know someone here will have the answer I need.
> 
> I'm using JDom to create XML that I then process with XSL via Xalan. My XSL
> is very simple I'm not even adding any of the XML data to it yet. I have an
> <a> tag that the Xalan is dying on. This is the error I get:
> 
> org.apache.xalan.xslt.XSLProcessorException: The reference to entity
> "subaction"  must end with the ';' delimiter.
> 
> This is the line it is dying on:
> 
> <a
> href='http://localhost/login/ActionServer?action=loadpage&subaction=html&fil
> eName=client-inquiry.html'>Client Inquiry</a>
> 
> I've included the XSL and have commented out the offending line. If someone
> could point out what I've done wrong I would greatly appreciated it.
> 
> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
>                 version="1.0"
> >
>   <xsl:template match="/">
>     <html>
>       <head><title>Main Menu</title></head>
> 
>       <body bgcolor="#FFFFFF">
>         <h2>Main Menu</h2>
>         <p>
> <!-- Why doesn't it like this line?
>         <a
> href='http://localhost/login/ActionServer?action=loadpage&subaction=html&fil
> eName=client-inquiry.html'>Client Inquiry</a>
> -->

          <xsl:element name="a">
            <xsl:attribute name="href">
             
http://localhost/login/ActionServer?action=loadpage&subaction=html&fileName=client-inquiry.html
            </xsl:attribute>
            Client Inquiry
          </xsl:element>

>         </p>
>       </body>
>     </html>
>   </xsl:template>
> </xsl:stylesheet>

Try that and see if it works.

-Brett

> 
> -----
> Damian Van Dooren
> Information Technology
> The Investment Centre
> (519) 672-4389 x718
> 
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org

From VanDoorenD at icfg.com  Mon Sep 18 09:57:44 2000
From: VanDoorenD at icfg.com (Van Dooren, Damian)
Date: Fri Aug  6 17:04:59 2004
Subject: [jdom-interest] Off Topic - XSL (Xalan) question
Message-ID: <9DA96145A87BD411BDAE0008C7A49B640117CA@mail.icfg.com>

Unfortunately it doesn't help. It comes back with the same error:

org.apache.xalan.xslt.XSLProcessorException: The reference to entity
"subaction"
 must end with the ';' delimiter.

I've even tried putting <xsl:text></xsl:text> around the text and I still
get the same error.


>           <xsl:element name="a">
>             <xsl:attribute name="href">
>              
> http://localhost/login/ActionServer?action=loadpage&subaction=
html&fileName=client-inquiry.html
            </xsl:attribute>
            Client Inquiry
          </xsl:element>

Try that and see if it works.

-Brett

> 
> -----
> Damian Van Dooren
> Information Technology
> The Investment Centre
> (519) 672-4389 x718
> 
> _______________________________________________
> To control your jdom-interest membership:
>
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org
_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com

From omenred at yahoo.com  Mon Sep 18 10:59:08 2000
From: omenred at yahoo.com (Omen Red)
Date: Fri Aug  6 17:04:59 2004
Subject: [jdom-interest] Element.getChildren() doesn't work ??
Message-ID: <20000918175908.5069.qmail@web2102.mail.yahoo.com>

Hi there,
 recently I have downloaded jdom-b3 and tryied to use
in my work, but what I found is that 
when I call function getChildren() in Element it
returns me list with doubled count of subelements.
For instance when I build document from 
"<A1><A2></A2><A2></A2></A1>" and call then
getChildren() for root element, I receive not 2 A2
elements but four!! Is it ok ? 
I went to the sources of jdom and found getChildren
function, and found following:

>>    public List getChildren() {
>>        PartialList elements = new
PartialList(content);
>>
>>        Iterator i = content.iterator();
>>        while (i.hasNext()) {
>>            Object obj = i.next();
>>            if (obj instanceof Element) {
>>                elements.addPartial(obj);
>>            }
>>        }
>>        return elements;
>>    }

As I understand from code above, first of all List of
subelements is created from "content" and then all
elements of "content" are added again. 
I don't get it. Of course I can use getMixedContent()
but what is the purpose of getChildren() function then
?

Thanx, best regards,
omen.

__________________________________________________
Do You Yahoo!?
Yahoo! Mail - Free email you can access from anywhere!
http://mail.yahoo.com/

From brett.mclaughlin at lutris.com  Mon Sep 18 11:26:44 2000
From: brett.mclaughlin at lutris.com (Brett McLaughlin)
Date: Fri Aug  6 17:04:59 2004
Subject: [jdom-interest] Element.getChildren() doesn't work ??
References: <20000918175908.5069.qmail@web2102.mail.yahoo.com>
Message-ID: <39C65E64.B004EB0A@lutris.com>


Omen Red wrote:
> 
> Hi there,
>  recently I have downloaded jdom-b3 and tryied to use
> in my work, but what I found is that
> when I call function getChildren() in Element it
> returns me list with doubled count of subelements.
> For instance when I build document from
> "<A1><A2></A2><A2></A2></A1>" and call then
> getChildren() for root element, I receive not 2 A2
> elements but four!! Is it ok ?
> I went to the sources of jdom and found getChildren
> function, and found following:

Get the latest version from CVS. Beta 3 and 4 are horribly behind.

Thanks,
Brett

> 
> >>    public List getChildren() {
> >>        PartialList elements = new
> PartialList(content);
> >>
> >>        Iterator i = content.iterator();
> >>        while (i.hasNext()) {
> >>            Object obj = i.next();
> >>            if (obj instanceof Element) {
> >>                elements.addPartial(obj);
> >>            }
> >>        }
> >>        return elements;
> >>    }
> 
> As I understand from code above, first of all List of
> subelements is created from "content" and then all
> elements of "content" are added again.
> I don't get it. Of course I can use getMixedContent()
> but what is the purpose of getChildren() function then
> ?
> 
> Thanx, best regards,
> omen.
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Mail - Free email you can access from anywhere!
> http://mail.yahoo.com/
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org

From Brad.Morgan at e-pubcorp.com  Mon Sep 18 12:16:09 2000
From: Brad.Morgan at e-pubcorp.com (Brad Morgan)
Date: Fri Aug  6 17:04:59 2004
Subject: [jdom-interest] JavaDoc build with JDK 1.1.8 generates lots of messages
In-Reply-To: <20000918175908.5069.qmail@web2102.mail.yahoo.com>
Message-ID: <NDBBLFGNKKGCBIJEAIJBKEPMCGAA.Brad.Morgan@e-pubcorp.com>

I don't get these messages when I build with JDK 1.3.  I don't know if they
are important or not so I included them here just in case.


bmorgan$ ./build11.sh javadoc

JDOM Build System
-------------------

Building with classpath
/usr/java1.1/lib/tools.jar:./lib/xerces.jar:./lib/ant.jar:/usr/java1.1/lib/d
ev.jar:/usr/java1.1/lib/classes.zip:/usr/java1.1/lib/rt.jar:./lib/collection
s.jar

Starting Ant...

Buildfile: build.xml

init:
----------- JDOM 1.0beta5 [2000] ------------

prepare:

prepare-src:

collections:
  [replace] Replacing java.util.Collection -->
com.sun.java.util.collections.Collection
  [replace] Replacing java.util.Map --> com.sun.java.util.collections.Map
  [replace] Replacing java.util.HashMap -->
com.sun.java.util.collections.HashMap
  [replace] Replacing java.util.List --> com.sun.java.util.collections.List
  [replace] Replacing java.util.LinkedList -->
com.sun.java.util.collections.LinkedList
  [replace] Replacing java.util.Set --> com.sun.java.util.collections.Set
  [replace] Replacing java.util.HashSet -->
com.sun.java.util.collections.HashSet
  [replace] Replacing java.util.Iterator -->
com.sun.java.util.collections.Iterator
  [replace] Replacing java.util.* --> java.util.*;\u000aimport
com.sun.java.util.collections.*

javadoc:
    [mkdir] Created dir: /home/bmorgan/jdom/build/apidocs
  [javadoc] Generating Javadoc
  [javadoc] Parsing source files for packages
  [javadoc] Could not evaluate package for
/home/bmorgan/jdom/build/src/Count.java
  [javadoc] Could not evaluate package for
/home/bmorgan/jdom/build/src/PrettyPrinter.java
  [javadoc] Could not evaluate package for
/home/bmorgan/jdom/build/src/ContentLister.java
  [javadoc] Could not evaluate package for
/home/bmorgan/jdom/build/src/WarReader.java
  [javadoc] Could not evaluate package for
/home/bmorgan/jdom/build/src/SAXBuilderDemo.java
  [javadoc] Could not evaluate package for
/home/bmorgan/jdom/build/src/DOMBuilderDemo.java
  [javadoc] Javadoc execution
  [javadoc] Loading source files for org.jdom
  [javadoc] Loading source files for org.jdom.adapters
  [javadoc] Loading source files for org.jdom.output
  [javadoc] Loading source files for org.jdom.input
  [javadoc] Generating documentation for class org.jdom.Attribute
  [javadoc] Method int getIntValue()
  [javadoc]     declares that it throws class
org.jdom.DataConversionException,
  [javadoc]     but there is no corresponding @exception item
  [javadoc] Method long getLongValue()
  [javadoc]     declares that it throws class
org.jdom.DataConversionException,
  [javadoc]     but there is no corresponding @exception item
  [javadoc] Method float getFloatValue()
  [javadoc]     declares that it throws class
org.jdom.DataConversionException,
  [javadoc]     but there is no corresponding @exception item
  [javadoc] Method double getDoubleValue()
  [javadoc]     declares that it throws class
org.jdom.DataConversionException,
  [javadoc]     but there is no corresponding @exception item
  [javadoc] Method boolean getBooleanValue()
  [javadoc]     declares that it throws class
org.jdom.DataConversionException,
  [javadoc]     but there is no corresponding @exception item
  [javadoc] Generating documentation for class org.jdom.output.DOMOutputter
  [javadoc] Method org.w3c.dom.Document output(org.jdom.Document)
  [javadoc]     declares that it throws class org.jdom.JDOMException,
  [javadoc]     but there is no corresponding @exception item
  [javadoc] Method org.w3c.dom.Element output(org.jdom.Element)
  [javadoc]     declares that it throws class org.jdom.JDOMException,
  [javadoc]     but there is no corresponding @exception item
  [javadoc] Method org.w3c.dom.Attr output(org.jdom.Attribute)
  [javadoc]     declares that it throws class org.jdom.JDOMException,
  [javadoc]     but there is no corresponding @exception item
  [javadoc] Method org.w3c.dom.Element output(org.jdom.Element,
java.lang.String)
  [javadoc]     declares that it throws class org.jdom.JDOMException,
  [javadoc]     but there is no corresponding @exception item
  [javadoc] Method org.w3c.dom.Document output(org.jdom.Document,
java.lang.String)
  [javadoc]     declares that it throws class org.jdom.JDOMException,
  [javadoc]     but there is no corresponding @exception item
  [javadoc] Method org.w3c.dom.Attr output(org.jdom.Attribute,
java.lang.String)
  [javadoc]     declares that it throws class org.jdom.JDOMException,
  [javadoc]     but there is no corresponding @exception item
  [javadoc] Generating documentation for class org.jdom.input.DOMBuilder
  [javadoc] Method org.jdom.Document build(java.io.InputStream)
  [javadoc]     declares that it throws class org.jdom.JDOMException,
  [javadoc]     but there is no corresponding @exception item
  [javadoc] Method org.jdom.Document build(java.io.File)
  [javadoc]     declares that it throws class org.jdom.JDOMException,
  [javadoc]     but there is no corresponding @exception item
  [javadoc] Method org.jdom.Document build(java.net.URL)
  [javadoc]     declares that it throws class org.jdom.JDOMException,
  [javadoc]     but there is no corresponding @exception item
  [javadoc] Generating documentation for class org.jdom.input.SAXBuilder
  [javadoc] Method org.jdom.Document build(org.xml.sax.InputSource)
  [javadoc]     declares that it throws class org.jdom.JDOMException,
  [javadoc]     but there is no corresponding @exception item
  [javadoc] Method org.jdom.Document build(java.io.InputStream)
  [javadoc]     declares that it throws class org.jdom.JDOMException,
  [javadoc]     but there is no corresponding @exception item
  [javadoc] Method org.jdom.Document build(java.io.File)
  [javadoc]     declares that it throws class org.jdom.JDOMException,
  [javadoc]     but there is no corresponding @exception item
  [javadoc] Method org.jdom.Document build(java.net.URL)
  [javadoc]     declares that it throws class org.jdom.JDOMException,
  [javadoc]     but there is no corresponding @exception item
  [javadoc] Method org.jdom.Document
build(java.io.InputStream,java.lang.String)
  [javadoc]     declares that it throws class org.jdom.JDOMException,
  [javadoc]     but there is no corresponding @exception item
  [javadoc] Method org.jdom.Document build(java.io.Reader)
  [javadoc]     declares that it throws class org.jdom.JDOMException,
  [javadoc]     but there is no corresponding @exception item
  [javadoc] Method org.jdom.Document build(java.io.Reader, java.lang.String)
  [javadoc]     declares that it throws class org.jdom.JDOMException,
  [javadoc]     but there is no corresponding @exception item
  [javadoc] Method org.jdom.Document build(java.lang.String)
  [javadoc]     declares that it throws class org.jdom.JDOMException,
  [javadoc]     but there is no corresponding @exception item
  [javadoc] Generating index
  [javadoc] Sorting 345 items...done

BUILD SUCCESSFUL

Total time: 6 minutes 2 seconds

Brad Morgan
e-Publishing Corp.

Email: Brad.Morgan@e-pubcorp.com
Phone: (719)593-7377 x35
Fax: (719)593-2996

e-Publishing Corp. is a BroadVision company
NOTICE: This message is intended only for the use of the Addressee and may
contain information that is PRIVILEGED and CONFIDENTIAL. If you are not the
intended recipient, dissemination of this communication is prohibited. If
you have received this communication in error, please erase all copies of
the message and its attachments and notify us immediately.



From EGalluzzo at synchrony.net  Mon Sep 18 13:11:53 2000
From: EGalluzzo at synchrony.net (Galluzzo, Eric)
Date: Fri Aug  6 17:04:59 2004
Subject: [jdom-interest] JavaDoc build with JDK 1.1.8 generates lots o
	f messages
Message-ID: <51C6625F6F63D211853B0008C74C1A1EFA77DA@corp-exchg-001.synchrony.net>


> -----Original Message-----
> From: Brad Morgan [mailto:Brad.Morgan@e-pubcorp.com]
> Sent: Monday, September 18, 2000 3:16 PM
> To: jdom-interest@jdom.org
> Subject: [jdom-interest] JavaDoc build with JDK 1.1.8 
> generates lots of
> messages
> 
> 
> I don't get these messages when I build with JDK 1.3.  I 
> don't know if they
> are important or not so I included them here just in case.
> 
> 
> bmorgan$ ./build11.sh javadoc

[snip]

Yup, I got these with JDK 1.1 as well.  They're probably because the Javadoc
comments use @throws (introduced in JDK 1.2) instead of @exception (which
has been there since 1.0).  Since I prefer JDK1.2's Javadoc output, I always
use that to generate docs anyway. :)

   - Eric

From tsasala at hifusion.com  Mon Sep 18 13:29:30 2000
From: tsasala at hifusion.com (tsasala@hifusion.com)
Date: Fri Aug  6 17:04:59 2004
Subject: [jdom-interest] getChildren() vs getElements()
References: <20000914054952.G18335@edamame.stinky.com> <20000915111639.H23172@edamame.stinky.com>
Message-ID: <39C67B2A.E1B2BF81@hifusion.com>

	+1 for getChildren.  makes more sense to *me*.

Alex Chaffee wrote:
> 
> Wait a second.  The +1s are coming fast and furious but...
> 
> I think getChildElements() is too verbose and also redundant.  Of
> course it's a child element; what other kind of element would it
> return?  A parent element?  A cousin? :-)
> 
> getElements() is not ambiguous.  It doesn't imply that it recurses any
> more than getChildren() implies that it recurses.  Once you accept
> that an element can contain elements, it is not confusing (it only
> sounds self-referential, but it's not).
> 
> The issue is terminological: there are many "children" of an element,
> but only some of them are elements.  Thus getElements() should return
> the children that are elements, getAttributes() should return the
> children that are attributes, and so forth.
> 
> So:
> 
> getChildren() should be renamed getElements()
> 
> (*not* getChildElements(), unless there's a corresponding change to
> getChildAttributes())
> 
> Likewise, getChild() should be renamed getElement().
> 
> addChild(...) is already deprecated so it's not a problem, though I
> actually believe addChild() is better than addContent() ("content"
> implies "text content of this node" not "some sort of child of this
> node")
> 
> getChildText(String name) is a convenience method anyway, but what
> would be the problem with renaming it getText(String name) ?  The
> presence of the parameter should clear up any ambiguity.
> 
> Then removeChild() / removeChildren() / setChildren() should be
> removeElement() / removeElements() / setElements()
> 
> Following this logic, "getMixedContent()" should be renamed
> "getChildren()" but that would be very confusing at this stage.  I'd
> still vote +1 for it but it would cause a deluge of misguided bug
> reports.
> 
> *That's* the proposal.  Not piecemeal, changing one name a dozen
> times.  The whole kit and kaboodle.  We accept, once and for all, that
> a child is not the same as an element.
> 
> Or not :-)
> 
>  - Alex
> 
> On Thu, Sep 14, 2000 at 05:49:52AM -0700, Alex Chaffee wrote:
> >
> > Wasn't there a discussion a few months ago about renaming
> > getChildren() to getElements()?  This Solomon-like solution was
> > provided by somebody smart, I think James.
> >
> > Recap:
> >
> > element.getChildren()
> >       ambiguous; implies that it gets Attributes etc. :-(
> >
> > element.getChildElements()
> >       too long to type :-(
> >
> > element.getElements()
> >       brief; no way it can be misinterpreted :-)
> >
> > Was this just forgotten, or was there a reason to keep getChildren
> > that I missed?
> >
> > (We could deprecate getChildren for a few months before the 1.0
> > release to allow migration.)
> >
> >  - Alex
> >
> > P.S. This is orthogonal to the current "Element implements List"
> > discussion.  BTW, I think it should not implement List, for this very
> > reason: there is an ambiguity as to what the members of that list
> > would be (elements or mixed or elements+attributes or ...)
> >
> >
> > --
> > Alex Chaffee                       mailto:alex@jguru.com
> > jGuru - Java News and FAQs         http://www.jguru.com/alex/
> > Creator of Gamelan                 http://www.gamelan.com/
> > Founder of Purple Technology       http://www.purpletech.com/
> > Curator of Stinky Art Collective   http://www.stinky.com/
> > _______________________________________________
> > To control your jdom-interest membership:
> > http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
> 
> --
> Alex Chaffee                       mailto:alex@jguru.com
> jGuru - Java News and FAQs         http://www.jguru.com/alex/
> Creator of Gamelan                 http://www.gamelan.com/
> Founder of Purple Technology       http://www.purpletech.com/
> Curator of Stinky Art Collective   http://www.stinky.com/
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com

-- 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ Thomas M. Sasala, Senior Developer             tsasala@hifusion.com     + 
+ HiFusion, Inc.                                 (W) 703.848.4441         +
+ 8180 Greensboro Dr, #500                       (F) 703.848.4420         +
+ McLean, VA  22102                                                       + 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

From Brad.Morgan at e-pubcorp.com  Mon Sep 18 14:33:01 2000
From: Brad.Morgan at e-pubcorp.com (Brad Morgan)
Date: Fri Aug  6 17:04:59 2004
Subject: [jdom-interest] JavaDoc build with JDK 1.1.8 generates lots of messages
In-Reply-To: <51C6625F6F63D211853B0008C74C1A1EFA77DA@corp-exchg-001.synchrony.net>
Message-ID: <NDBBLFGNKKGCBIJEAIJBEEPNCGAA.Brad.Morgan@e-pubcorp.com>

Since the build script makes a pass through the sources to munge all the
collection references, would it make sense to change all the "@throws" to
"@exception" as well?

Brad

-----Original Message-----
Yup, I got these with JDK 1.1 as well.  They're probably because the Javadoc
comments use @throws (introduced in JDK 1.2) instead of @exception (which
has been there since 1.0).  Since I prefer JDK1.2's Javadoc output, I always
use that to generate docs anyway. :)

   - Eric
_______________________________________________


From omenred at yahoo.com  Mon Sep 18 18:45:36 2000
From: omenred at yahoo.com (Omen Red)
Date: Fri Aug  6 17:04:59 2004
Subject: [jdom-interest] Element.getChildren() doesn't work ??
Message-ID: <20000919014536.22522.qmail@web2106.mail.yahoo.com>

Thanx, Element.getChildren() works fine with latest
releases (jdom-b5?). 

but, +1 for Element.getElements()

thanx again, om.

--- Brett McLaughlin <brett.mclaughlin@lutris.com>
wrote:
> 
> 
> Omen Red wrote:
> > 
> > Hi there,
> >  recently I have downloaded jdom-b3 and tryied to
> use
> > in my work, but what I found is that
> > when I call function getChildren() in Element it
> > returns me list with doubled count of subelements.
> > For instance when I build document from
> > "<A1><A2></A2><A2></A2></A1>" and call then
> > getChildren() for root element, I receive not 2 A2
> > elements but four!! Is it ok ?
> > I went to the sources of jdom and found
> getChildren
> > function, and found following:
> 
> Get the latest version from CVS. Beta 3 and 4 are
> horribly behind.
> 
> Thanks,
> Brett
>> ....


__________________________________________________
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/

From mbreig at i2ag.de  Tue Sep 19 00:01:39 2000
From: mbreig at i2ag.de (Marcus Breig)
Date: Fri Aug  6 17:04:59 2004
Subject: [jdom-interest] DTD im XML-File and Element.getContent()
References: <39C6098E.5B70447F@i2ag.de> <39C62565.2575F21A@lutris.com>
Message-ID: <39C70F52.CB2429FB@i2ag.de>

Hi Brett,

the XML-File (with DTD) in the attachment...

Marcus

Brett McLaughlin schrieb:

> Marcus Breig wrote:
> > My problem: my sample XML-File contains a DTD for
> > defining my XML-language. In this case the method
> > Element.getContent() always returns an empty string.
>
> Can you post your XML document? I think I know what this is, but I want
> to make sure.
>
> Thanks
> Brett
-------------- next part --------------
A non-text attachment was scrubbed...
Name: users.xml
Type: text/xml
Size: 3579 bytes
Desc: not available
Url : http://jdom.org/pipermail/jdom-interest/attachments/20000919/4f1e794f/users.xml
From traversw at innoforge.co.za  Tue Sep 19 01:58:54 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:04:59 2004
Subject: [jdom-interest] no method: Element.setName(String). Why?
Message-ID: <009b01c02217$d810b660$1501a8c0@travers>

Hi all.

I've found a need for the following method of the Element class (but it
doesn't exist):

 Element.setName(String name)

Is there a technical reason why this method can't exist in the current Jdom?

At the moment I'm getting around this limitations as follows:
use Element.getCopy(String name) to create a clone (deep copy) of the
element.  This is pretty wasteful, because I don't need the original element
tree any more and would liek to reuse it with a new root element name
instread of doing expensive deep copies.

In case you're interested in where I'm applying this: It's to represent
request and response message pairs.  In most cases, the XML request message
is exactly the same as the response message except for:
1. The root element is called {something}ResponseMessage instead of
{something}RequestMessage.
2. The addition of a  ResponseCode child element.
3. The addition of a ResponseMessage child element.

2 and 3 are easy to do with Jdom, but changing the name of the root element
is not.

Thanks for any help or info.

Travers



From aidan at concordianet.com  Tue Sep 19 02:50:15 2000
From: aidan at concordianet.com (Aidan Killian)
Date: Fri Aug  6 17:05:00 2004
Subject: [jdom-interest] Re: Off Topic - XSL (Xalan) question
References: <200009182202.QAA24236@dorothy.denveronline.net>
Message-ID: <39C736D7.E88EEB73@concordianet.com>

jdom-interest-request@jdom.org wrote:

>
> From: "Van Dooren, Damian" <VanDoorenD@icfg.com>
> To: "JDOM (E-mail)" <jdom-interest@jdom.org>
> Date: Mon, 18 Sep 2000 11:43:32 -0400
> charset="iso-8859-1"
> Subject: [jdom-interest] Off Topic - XSL (Xalan) question
>
> ...
>
> org.apache.xalan.xslt.XSLProcessorException: The reference to entity
> "subaction"  must end with the ';' delimiter.
>
> This is the line it is dying on:
>
> <a
> href='http://localhost/login/ActionServer?action=loadpage&subaction=html&fil
> eName=client-inquiry.html'>Client Inquiry</a>
>
> I've included the XSL and have commented out the offending line. If someone
> could point out what I've done wrong I would greatly appreciated it.
>
> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
>                 version="1.0"
> >
>   <xsl:template match="/">
>     <html>
>       <head><title>Main Menu</title></head>
>
>       <body bgcolor="#FFFFFF">
>         <h2>Main Menu</h2>
>         <p>
> <!-- Why doesn't it like this line?
>         <a
> href='http://localhost/login/ActionServer?action=loadpage&subaction=html&fil
> eName=client-inquiry.html'>Client Inquiry</a>
> -->
>         </p>
>       </body>
>     </html>
>   </xsl:template>
> </xsl:stylesheet>
>
> Hi Damian,

    The parameter separator in the URL is being interpreted as an entity
reference open; an XML parser sees '&subaction' and says where is the
entity reference close (';').

    You need to escape the '&'s using '&amp;'s as follows (line wrapped by me):

href='http://localhost/login/ActionServer?action=loadpage&amp;
subaction=html&amp;fileName=client-inquiry.html'>

Regards,
    Aidan Killian



From ssmith at neonsys.com  Tue Sep 19 08:50:59 2000
From: ssmith at neonsys.com (Steven Smith)
Date: Fri Aug  6 17:05:00 2004
Subject: [jdom-interest] Problem with DTD
Message-ID: <8625695F.00578F61.00@internet1.neonsys.com>



(Embedded image moved to file: pic22322.pcx)   Steven Smith @ NEON
09/19/2000 10:50 AM


My apologies for the most basis of questions....

I have a very simple XML document that I'm trying to manipulate with JDOM.
The DOCTYPE is as follows:

     <!DOCTYPE test SYSTEM "test.dtd">

When I attempt to construct a Document via SAXBuilder.build(), I get the
following exception:

     org.jdom.JDOMException: File "test.dtd" not found.: Error on line 0:
File "test.dtd" not found.

I am running my program from the command prompt in Windows 2000 and
test.dtd is in my current directory.  I don't understand why the dtd can't
be located.

Any help would be most appreciated.

Thanks,

Steven
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic22322.pcx
Type: application/octet-stream
Size: 1522 bytes
Desc: not available
Url : http://jdom.org/pipermail/jdom-interest/attachments/20000919/97b07f8c/pic22322.obj
From Nick.Reeves at gtl.com  Tue Sep 19 07:40:03 2000
From: Nick.Reeves at gtl.com (Nick Reeves)
Date: Fri Aug  6 17:05:00 2004
Subject: [jdom-interest] static data needs to be thread data for multithreaded application
 s
Message-ID: <AF7105DDF744D311A7DF005004B07090C6DF49@exchange1.gtl.com>

Let me make clear first of all I am not asking for individual JDOM Objects
to be thread safe. I fully agree that the caller should be responsible for
this, following the example of the Java Collections API.

However where the class has hidden static data (such as
Namespace.namespaces)the class must be responsible for making access to this
thread safe otherwise multithreaded applications such as your typical Web or
EJB case, have no choice but to single thread all use of the JDOM packages
:(. This would lead to appalling performance in any realistic use.

At present multihreaded use of Namespace.getNamespace even indirectly (eg by
importing files in different threads) will cause random failures with
ConcurrentModificationException.


From kendrick at us.ibm.com  Tue Sep 19 10:13:44 2000
From: kendrick at us.ibm.com (kendrick@us.ibm.com)
Date: Fri Aug  6 17:05:00 2004
Subject: [jdom-interest] XMLOutputter - setExpandEmptyElements(true) not functioning
 properly.
Message-ID: <8525695F.005ECF4D.00@d54mta02.raleigh.ibm.com>


I am seeing my empty elements (content of an empty String) outputted in the
shorthand format (<tagName />) even after I issued
setExpandEmptyElements(true).  I traced the code in XMLOutputter.
printElement() to:

     ...
     if (empty) {
          // Simply close up
          if (!expandEmptyElements) {
               out.write(" />");
          } else {
               out.write("></");
               out.write(element.getQualifiedName());
               out.write(">");
          }
          maybePrintln(out);
     } else if (stringOnly) {
          // Print the tag  with String on same line
          // Example: <tag name="value">content</tag>
          // Also handle "" being added to content
          String elementText = element.getText();
          if ((elementText != null) && (!elementText.equals(""))) {
               out.write(">");
               out.write(escapeElementEntities(element.getText()));
               out.write("</");
               out.write(element.getQualifiedName());
               out.write(">");
          } else {
==========>
== here ==>         out.write(" />");
==========>
          }
          maybePrintln(out);
     } else {
     ...

Apparently the check for expandEmptyElements needs to occur here as well.

Sincerely,
Shannon

IBM e-business Integration Services
3200 Windy Hill Road - Atlanta, GA 30332 - WG06B
Phone: 770-835-7672 T/L 445   FAX: 770-835-6479
Internet: kendrick@us.ibm.com



From wwerner at picturesafe.de  Tue Sep 19 13:15:44 2000
From: wwerner at picturesafe.de (Wolfgang Werner)
Date: Fri Aug  6 17:05:00 2004
Subject: [jdom-interest] [BUG]
Message-ID: <BAEGIHMHEJPCJDLGDHMGOEGFDHAA.wwerner@picturesafe.de>

Hello, 

I think I found a very small Bug in Element.java:

If you create an Element without textual content, e.g

	Element e = new Element("test");

and put it into an Document, the function

	e.getText() 

on this element fails with a NullPointerException due to the 
shortcut in the first lines: Access to content.

A short look at the code reveals that other funtions do a
test for this before atempting to access the content list.

Did I miss something? I tested this on the CVS code from 
(i think) two days ago.

Thanks, 

	Wolfgang Werner

From brett.mclaughlin at lutris.com  Tue Sep 19 17:27:45 2000
From: brett.mclaughlin at lutris.com (Brett McLaughlin)
Date: Fri Aug  6 17:05:00 2004
Subject: [jdom-interest] [BUG]
References: <BAEGIHMHEJPCJDLGDHMGOEGFDHAA.wwerner@picturesafe.de>
Message-ID: <39C80481.E5E595D7@lutris.com>


Wolfgang Werner wrote:
> 
> Hello,
> 
> I think I found a very small Bug in Element.java:
> 
> If you create an Element without textual content, e.g
> 
>         Element e = new Element("test");
> 
> and put it into an Document, the function
> 
>         e.getText()
> 
> on this element fails with a NullPointerException due to the
> shortcut in the first lines: Access to content.
> 
> A short look at the code reveals that other funtions do a
> test for this before atempting to access the content list.
> 
> Did I miss something? I tested this on the CVS code from
> (i think) two days ago.

I fixed this ... give it a try now with the latest from CVS.

-Brett

> 
> Thanks,
> 
>         Wolfgang Werner
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org

From brett.mclaughlin at lutris.com  Tue Sep 19 17:30:10 2000
From: brett.mclaughlin at lutris.com (Brett McLaughlin)
Date: Fri Aug  6 17:05:00 2004
Subject: [jdom-interest] XMLOutputter - setExpandEmptyElements(true) not 
 functioningproperly.
References: <8525695F.005ECF4D.00@d54mta02.raleigh.ibm.com>
Message-ID: <39C80512.561AA03B@lutris.com>


kendrick@us.ibm.com wrote:
> 
> I am seeing my empty elements (content of an empty String) outputted in the
> shorthand format (<tagName />) even after I issued
> setExpandEmptyElements(true).  I traced the code in XMLOutputter.
> printElement() to:
> 
>      ...
>      if (empty) {
>           // Simply close up
>           if (!expandEmptyElements) {
>                out.write(" />");
>           } else {
>                out.write("></");
>                out.write(element.getQualifiedName());
>                out.write(">");
>           }
>           maybePrintln(out);
>      } else if (stringOnly) {
>           // Print the tag  with String on same line
>           // Example: <tag name="value">content</tag>
>           // Also handle "" being added to content
>           String elementText = element.getText();
>           if ((elementText != null) && (!elementText.equals(""))) {
>                out.write(">");
>                out.write(escapeElementEntities(element.getText()));
>                out.write("</");
>                out.write(element.getQualifiedName());
>                out.write(">");
>           } else {
> ==========>
> == here ==>         out.write(" />");
> ==========>
>           }
>           maybePrintln(out);
>      } else {
>      ...
> 
> Apparently the check for expandEmptyElements needs to occur here as well.

Yup. Just fixed it - try it now, and let me know if it works.

Thanks,
Brett

> 
> Sincerely,
> Shannon
> 
> IBM e-business Integration Services
> 3200 Windy Hill Road - Atlanta, GA 30332 - WG06B
> Phone: 770-835-7672 T/L 445   FAX: 770-835-6479
> Internet: kendrick@us.ibm.com
> 
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org

From brett.mclaughlin at lutris.com  Tue Sep 19 17:32:17 2000
From: brett.mclaughlin at lutris.com (Brett McLaughlin)
Date: Fri Aug  6 17:05:00 2004
Subject: [jdom-interest] DTD im XML-File and Element.getContent()
References: <39C6098E.5B70447F@i2ag.de> <39C62565.2575F21A@lutris.com> <39C70F52.CB2429FB@i2ag.de>
Message-ID: <39C80591.E0C8BD22@lutris.com>


Marcus Breig wrote:
> 
> Hi Brett,
> 
> the XML-File (with DTD) in the attachment...

Ahhh, yes. We have some known problems with inline DOCTYPE definitions -
I will work on this soon, and report the fix. Thanks!

-Brett

> 
> Marcus
> 
> Brett McLaughlin schrieb:
> 
> > Marcus Breig wrote:
> > > My problem: my sample XML-File contains a DTD for
> > > defining my XML-language. In this case the method
> > > Element.getContent() always returns an empty string.
> >
> > Can you post your XML document? I think I know what this is, but I want
> > to make sure.
> >
> > Thanks
> > Brett
> 
>   ------------------------------------------------------------------------
> <?xml version='1.0' encoding="ISO-8859-1" standalone="yes" ?>
> 
> <!DOCTYPE users [
> 
>         <!ELEMENT users (groups, user+) >
> 
>                 <!ELEMENT groups (group)+ >
>                         <!ELEMENT group (members, accessRights, commandRights)+ >
>                         <!ATTLIST group name CDATA #REQUIRED >
>                                 <!ELEMENT members (member)+ >
>                                         <!ELEMENT member (#PCDATA) >
>                                 <!ELEMENT accessRights (table)+ >
>                                         <!ELEMENT table EMPTY >
>                                         <!ATTLIST table name CDATA #REQUIRED >
>                                         <!ATTLIST table canRead (true|false) "false" >
>                                         <!ATTLIST table canWrite (true|false) "false" >
>                                 <!ELEMENT commandRights (tableCmds)+  >
>                                         <!ELEMENT tableCmds (command)+ >
>                                         <!ATTLIST tableCmds tablename CDATA #REQUIRED >
>                                                 <!ELEMENT command EMPTY >
>                                                 <!ATTLIST command name CDATA #REQUIRED >
>                                                 <!ATTLIST command allowed (true|false) "false" >
>                 <!ELEMENT user (config, accessRights*, commandRights*, information*) >
>                         <!ELEMENT config (nickname, top, store) >
>                                 <!ELEMENT nickname (#PCDATA) >
>                                 <!ELEMENT top (#PCDATA) >
>                                 <!ELEMENT store (#PCDATA) >
>                         <!ELEMENT information (nachname, vorname, anschrift, plz, ort, telefon, telefax, email) >
>                                 <!ELEMENT nachname (#PCDATA) >
>                                 <!ELEMENT vorname (#PCDATA) >
>                                 <!ELEMENT anschrift (#PCDATA) >
>                                 <!ELEMENT plz (#PCDATA) >
>                                 <!ELEMENT ort (#PCDATA) >
>                                 <!ELEMENT telefon (#PCDATA) >
>                                 <!ELEMENT telefax (#PCDATA) >
>                                 <!ELEMENT email (#PCDATA) >
> ]>
> 
> <!-- hier folgt die Beschreibung der Benutzergruppen, Zugriffsrechte und Benutzer -->
> 
> <users>
> 
>         <groups>
> 
>                 <group name="projektleiter">
>                         <members>
>                                 <member>MB</member>
>                                 <member>RS</member>
>                         </members>
>                         <accessRights>
>                                 <table name="adressen" canRead="true" canWrite="true" />
>                                 <table name="dokumente" canRead="true" canWrite="true" />
>                                 <table name="projekte" canRead="true" canWrite="true" />
>                         </accessRights>
>                         <commandRights>
>                                 <tableCmds tablename="adressen">
>                                         <command name="new" allowed="true" />
>                                         <command name="edit" allowed="true" />
>                                         <command name="delete" allowed="true" />
>                                         <command name="copy" allowed="true" />
>                                 </tableCmds>
>                                 <tableCmds tablename="dokumente">
>                                         <command name="new" allowed="true" />
>                                         <command name="edit" allowed="true" />
>                                         <command name="export" allowed="true" />
>                                         <command name="import" allowed="true" />
>                                         <command name="lock" allowed="true" />
>                                         <command name="copy" allowed="true" />
>                                         <command name="release" allowed="true" />
>                                         <command name="delete" allowed="true" />
>                                         <command name="view" allowed="true" />
>                                 </tableCmds>
>                                 <tableCmds tablename="projekte">
>                                         <command name="new" allowed="true" />
>                                         <command name="edit" allowed="true" />
>                                         <command name="delete" allowed="true" />
>                                         <command name="copy" allowed="true" />
>                                 </tableCmds>
>                         </commandRights>
>                 </group>
>         </groups>
> 
>         <user>
>                 <config>
>                         <nickname>SM</nickname>
>                         <top>/</top>
>                         <store>/ENTWICKLUNG/SOURCE/SM</store>
>                 </config>
>                 <information>
>                         <nachname>Meisner</nachname>
>                         <vorname>Hans Georg-Stefan Andreas Bernhard</vorname>
>                         <anschrift>L?nener Str. 31</anschrift>
>                         <plz>40472</plz>
>                         <ort>D?sseldorf</ort>
>                         <telefon>0211-6011976</telefon>
>                         <telefax>-</telefax>
>                         <email>sm@i2ag.de</email>
>                 </information>
>         </user>
>         <user>
>                 <config>
>                         <nickname>ML</nickname>
>                         <top>/</top>
>                         <store>/ML</store>
>                 </config>
>                 <information>
>                         <nachname>Loges</nachname>
>                         <vorname>Marc</vorname>
>                         <anschrift>-</anschrift>
>                         <plz>00000</plz>
>                         <ort>Wuppertal</ort>
>                         <telefon>0202-???</telefon>
>                         <telefax>-</telefax>
>                         <email>ml@kbld.de</email>
>                 </information>
>         </user>
> </users>

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org

From sgandon at canal-plus.fr  Wed Sep 20 02:17:50 2000
From: sgandon at canal-plus.fr (sgandon@canal-plus.fr)
Date: Fri Aug  6 17:05:00 2004
Subject: [jdom-interest] how to do DTD validation of newly created XML document ?
Message-ID: <NDBBJBMKJKPDLLDKIJIIKEAECGAA.sgandon@canal-plus.fr>

Hello,
I am new to xml and therefore new to the use of JDOM.
I need to create a xml document from scratch excepting that I have a DTD, I
would like to know how to check the validity of my document before saving
it?
Do I have to save it and build another document through a SAXBuilder so that
parsing validates it or there any other way to do that before saving (using
XMLOutputter)?

Thank you
Sebastien.


From jools at jools.org  Wed Sep 20 03:09:30 2000
From: jools at jools.org (Jools Enticknap)
Date: Fri Aug  6 17:05:00 2004
Subject: [jdom-interest] static data needs to be thread data for 
 multithreaded applications
References: <AF7105DDF744D311A7DF005004B07090C6DF49@exchange1.gtl.com>
Message-ID: <39C88CDA.726BEF90@jools.org>

Nick Reeves wrote:
> 
> Let me make clear first of all I am not asking for individual JDOM Objects
> to be thread safe. I fully agree that the caller should be responsible for
> this, following the example of the Java Collections API.
> 
> However where the class has hidden static data (such as
> Namespace.namespaces)the class must be responsible for making access to this
> thread safe otherwise multithreaded applications such as your typical Web or
> EJB case, have no choice but to single thread all use of the JDOM packages
> :(. This would lead to appalling performance in any realistic use.
> 
> At present multihreaded use of Namespace.getNamespace even indirectly (eg by
> importing files in different threads) will cause random failures with
> ConcurrentModificationException.

Hi Nick

I'm using JDOM in a multithreaded EJB application, and I've not come
across
any issues so far, and I'd hate to have something like this slip through
my 
fingers prior to deployment ;-(

BTW I'm using a fairly simple methodology, one update thread, and
multiple
read threads. I've not seen any problems as yet.

--Jools

From philipp.zuderell at tanner.de  Wed Sep 20 04:54:47 2000
From: philipp.zuderell at tanner.de (Philipp Zuderell)
Date: Fri Aug  6 17:05:00 2004
Subject: [jdom-interest] Document.getSerializedForm()
Message-ID: <39C8A587.1604D1BD@tanner.de>

Hi all,

I need a String-representation of a Document object, in order to pass it
to my JavaMail client to send it along as an eMail attachment.
Unfortunately, Document.getSerializedForm() doesn't work.
When is it expected to be implemented?
Is there another way to get a String representation of a Document
object?

Thanks in advance

-- phil


--
P.S. Tanner Dokuments ist umgezogen, bitte geaenderte
     Adresse beachten! - Tanner Dokuments has moved;
     please notice the changed address!

----------------------------------------------------
Tanner Dokuments GmbH+Co
Philipp Zuderell
Kemptener Strasse 99
D-88131 Lindau
Germany

tel +49(0)8382/272-278
fax +49(0)8382/272-900
mailto:philipp.zuderell@tanner.de
http://www.tanner.de
----------------------------------------------------



From guyn at tantian.com  Wed Sep 20 06:50:41 2000
From: guyn at tantian.com (Guy Nirpaz)
Date: Fri Aug  6 17:05:00 2004
Subject: [jdom-interest] Document.getSerializedForm()
References: <39C8A587.1604D1BD@tanner.de>
Message-ID: <006d01c02309$c5a3fb70$080aa8c0@tantian.local>

Hi Phil -

You should use the org.jdom.XMLOutputter -

    something like

  XMLOutputter outputter = new XMLOutputter("     ",true);
  outputter.output(doc, System.out);

instead of System.out - you can put any java.io.Reader or
java.io.OutputStream

-Guy

----- Original Message -----
From: "Philipp Zuderell" <philipp.zuderell@tanner.de>
To: <jdom-interest@jdom.org>
Sent: Wednesday, September 20, 2000 1:54 PM
Subject: [jdom-interest] Document.getSerializedForm()


> Hi all,
>
> I need a String-representation of a Document object, in order to pass it
> to my JavaMail client to send it along as an eMail attachment.
> Unfortunately, Document.getSerializedForm() doesn't work.
> When is it expected to be implemented?
> Is there another way to get a String representation of a Document
> object?
>
> Thanks in advance
>
> -- phil
>
>
> --
> P.S. Tanner Dokuments ist umgezogen, bitte geaenderte
>      Adresse beachten! - Tanner Dokuments has moved;
>      please notice the changed address!
>
> ----------------------------------------------------
> Tanner Dokuments GmbH+Co
> Philipp Zuderell
> Kemptener Strasse 99
> D-88131 Lindau
> Germany
>
> tel +49(0)8382/272-278
> fax +49(0)8382/272-900
> mailto:philipp.zuderell@tanner.de
> http://www.tanner.de
> ----------------------------------------------------
>
>
> _______________________________________________
> To control your jdom-interest membership:
>
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com
>


From kmorehead at idiominc.com  Wed Sep 20 06:09:49 2000
From: kmorehead at idiominc.com (Kem Morehead)
Date: Fri Aug  6 17:05:00 2004
Subject: [jdom-interest] NoSuchElementException
Message-ID: <43EA80F14C3ED411841D00508BAE017D1D072B@wal-zulu.idiomtech.com>

I just downloaded the most recent snapshot (because I need CDATA) and I'm
noticing a number of things deprecated or gone. I realize if I had been
following the mailing list more closely I would have known this, but I
haven't. However, I have searched the mailing list and found nothing about
eliminating NoSuchElementException. Is it now assumed that we should use the
generic JDOMException instead? Any idea when the jdocs on the web site will
be updated?

Thanks.

kem

-------------------------------------------------
Kem Morehead, software engineer
Idiom, Inc. [www.idiominc.com]
781.464.6113
kmorehead@idiominc.com


From guru at edamame.stinky.com  Wed Sep 20 07:52:20 2000
From: guru at edamame.stinky.com (Alex Chaffee)
Date: Fri Aug  6 17:05:00 2004
Subject: [jdom-interest] A plea for the orphans
In-Reply-To: <20000916194723.A22473@talsever.com>; from amyzing@talsever.com on Sat, Sep 16, 2000 at 07:47:23PM -0400
References: <20000916122709.A21612@talsever.com> <39C3E267.3E9F9D00@collab.net> <20000916194723.A22473@talsever.com>
Message-ID: <20000920075220.B5659@edamame.stinky.com>

>  I can think of
> reasons not to store parentage inside each thing where we can do so
> (performance reasons, primarily--it's just a lot simpler to have
> one-way links; maintenance of double links is harder, which means it
> requires more bullet-proofing, which costs, and it still is likely to
> break more often than single linkage),

Another reason is that it closes the door on one possible
implementation of ID/IDREF.  I can imagine an Element appearing many
places in the tree, one time via ID, the rest via IDREF.

However, like I said, this is only one possible implementation, and
I'm not sure it's the right one.  For one thing, it would preclude
regenerating the same XML if the first appearance is not the canonical
one.

Another implementation of ID/IDREF would make a subclass of Element
called Reference that would proxy its calls over to the original
Element, but would be special enough that an XMLOutputter would know
the difference.  Also, a getID() method would not be out of the
question for both Element and Reference (since the ID attribute can
actually have any name, and it's non-trivial to figure out what it
is).  This is a very slippery slope.

> and am willing to accept those
> sorts of arguments (for folks that don't need that behavior, the price
> may be too high), but the fact that it can't be made consistent 'cause
> String is final doesn't much move me.

I am leaning away from getParent() for other reasons, mostly the ones
you mentioned (API simplicity and the annoying nature of
bi-directional links).

For navigation, what's wrong with maintaining a stack and passing it
along, or just using recursion?  Stacks are dead easy in Java: see
java.util.Stack.

I just noticed that Element.getParent() already exists.  How long has
that been so?

 - A

-- 
Alex Chaffee                       mailto:alex@jguru.com
jGuru - Java News and FAQs         http://www.jguru.com/alex/
Creator of Gamelan                 http://www.gamelan.com/
Founder of Purple Technology       http://www.purpletech.com/
Curator of Stinky Art Collective   http://www.stinky.com/

From jools at jools.org  Wed Sep 20 08:41:57 2000
From: jools at jools.org (Jools Enticknap)
Date: Fri Aug  6 17:05:00 2004
Subject: [jdom-interest] NoSuchElementException
References: <43EA80F14C3ED411841D00508BAE017D1D072B@wal-zulu.idiomtech.com>
Message-ID: <39C8DAC5.A240FC76@jools.org>

> I just downloaded the most recent snapshot (because I need CDATA) and I'm
> noticing a number of things deprecated or gone. I realize if I had been
> following the mailing list more closely I would have known this, but I
> haven't. However, I have searched the mailing list and found nothing about
> eliminating NoSuchElementException. Is it now assumed that we should use the
> generic JDOMException instead? Any idea when the jdocs on the web site will
> be updated?

Could'nt find anything about NoSuchElementException ?

You must be Joking. It was an epic.

If an Element cannot be found a null will be returned.

As for the java docs on the website, I think this was raised a few days
ago,
and I think they still represent the last beta drop, but I could be
wrong.



--Jools

From jhunter at collab.net  Wed Sep 20 09:26:16 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:05:00 2004
Subject: [jdom-interest] NoSuchElementException
References: <43EA80F14C3ED411841D00508BAE017D1D072B@wal-zulu.idiomtech.com>
Message-ID: <39C8E528.EA1D47@collab.net>

> However, I have searched the mailing list and found nothing about
> eliminating NoSuchElementException. 

There was tons of traffic, but under the topic of what those methods
should do if the child doesn't exist: return null or throw an
exception.  Returning null won out.  The web Javadocs represent the last
beta and yeah we're ready for another.  I apologize we haven't moved
faster on that.  Other demands take priority.  (I'm in Germany right now
helping OpenOffice.org get ready for its big launch!)

-jh-

From guru at edamame.stinky.com  Wed Sep 20 10:08:15 2000
From: guru at edamame.stinky.com (Alex Chaffee)
Date: Fri Aug  6 17:05:00 2004
Subject: [jdom-interest] BeanMapper
Message-ID: <20000920100815.F5659@edamame.stinky.com>

Because there weren't enough XML Data Binding technologies already, I
just wrote one using JDOM.

org.jdom.contrib.beans.BeanMapper allows you to easily (I'd say
'trivially' but that would be taunting the gods) make a JDOM tree from
an existing JavaBean, and/or instantiate-and-fill one of your JavaBean
classes based on a JDOM tree.  By default it maps element names and
property names directly, but you can override that by setting
mappings; e.g. getFoo() could map to <foo>foovalue</foo> (the default)
or <bar>foovalue</bar> or <baz baf="foovalue">.

Usage:

BeanMapper mapper = new BeanMapper();

// Converting Bean to JDOM
Document doc = mapper.toDocument(mybean);

// Converting JDOM to Bean
TestBean mybean = mapper.toBean(doc);


It uses reflection, so it's not super-fast, but it's meant as a quick
way to get started if you've got a a lot of beans already written and
want to do XML import/export.

I seem to have misplaced my CVS password.  Jools, can you please
contact me about checking this in?  In the meantime, anyone who wants
to play, please email me privately.

 - A

-- 
Alex Chaffee                       mailto:alex@jguru.com
jGuru - Java News and FAQs         http://www.jguru.com/alex/
Creator of Gamelan                 http://www.gamelan.com/
Founder of Purple Technology       http://www.purpletech.com/
Curator of Stinky Art Collective   http://www.stinky.com/

From guru at edamame.stinky.com  Wed Sep 20 10:10:13 2000
From: guru at edamame.stinky.com (Alex Chaffee)
Date: Fri Aug  6 17:05:00 2004
Subject: [jdom-interest] Document.getSerializedForm()
In-Reply-To: <39C8A587.1604D1BD@tanner.de>; from philipp.zuderell@tanner.de on Wed, Sep 20, 2000 at 01:54:47PM +0200
References: <39C8A587.1604D1BD@tanner.de>
Message-ID: <20000920101013.G5659@edamame.stinky.com>

Weren't we going to kill getSerializedForm, to encourage people to use
XMLOutputter instead?

 - A

On Wed, Sep 20, 2000 at 01:54:47PM +0200, Philipp Zuderell wrote:
> Hi all,
> 
> I need a String-representation of a Document object, in order to pass it
> to my JavaMail client to send it along as an eMail attachment.
> Unfortunately, Document.getSerializedForm() doesn't work.
> When is it expected to be implemented?
> Is there another way to get a String representation of a Document
> object?
> 
> Thanks in advance
> 
> -- phil
> 
> 
> --
> P.S. Tanner Dokuments ist umgezogen, bitte geaenderte
>      Adresse beachten! - Tanner Dokuments has moved;
>      please notice the changed address!
> 
> ----------------------------------------------------
> Tanner Dokuments GmbH+Co
> Philipp Zuderell
> Kemptener Strasse 99
> D-88131 Lindau
> Germany
> 
> tel +49(0)8382/272-278
> fax +49(0)8382/272-900
> mailto:philipp.zuderell@tanner.de
> http://www.tanner.de
> ----------------------------------------------------
> 
> 
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com

-- 
Alex Chaffee                       mailto:alex@jguru.com
jGuru - Java News and FAQs         http://www.jguru.com/alex/
Creator of Gamelan                 http://www.gamelan.com/
Founder of Purple Technology       http://www.purpletech.com/
Curator of Stinky Art Collective   http://www.stinky.com/

From guru at edamame.stinky.com  Wed Sep 20 10:22:41 2000
From: guru at edamame.stinky.com (Alex Chaffee)
Date: Fri Aug  6 17:05:00 2004
Subject: [jdom-interest] getChildren() vs getElements()
In-Reply-To: <704ECFDA88B3D311B5F000A0C959E5B601FBF0@adobo.c2labs.com>; from pvg@c-c-s.com on Sat, Sep 16, 2000 at 07:29:58AM -0700
References: <704ECFDA88B3D311B5F000A0C959E5B601FBF0@adobo.c2labs.com>
Message-ID: <20000920102240.H5659@edamame.stinky.com>

> Actually, I went back and re-read the last set of emails and noticed
> getChildAttributes in Alex's proposal and my badly quoted +1 -
> getChildAttributes is undoubtedly wrong, under any spec. No spec describes
> an attribute as a child. This also explains Jason's -50. My mistake, I
> quoted more than I meant to above my +1. 

Defensively: getChildAttributes() was not part of my proposal.  I said
*IF* we go with getChildElements(), *THEN* we must go with
getChildAttributes() for consistency.  I meant this as a
contrapositive subjunctive. 

My proposal was in fact the opposite: to go with getElements() and
getAttributes().

I think it would be ugly to to have getChildX and getY for all X, Y
where X and Y are similar concepts.

In fact, I'll go out on a limb and say that getChildren() is better
than getChildElements() -- conciseness wins over strict accuracy.

But getElements() has both.

 - Alex

-- 
Alex Chaffee                       mailto:alex@jguru.com
jGuru - Java News and FAQs         http://www.jguru.com/alex/
Creator of Gamelan                 http://www.gamelan.com/
Founder of Purple Technology       http://www.purpletech.com/
Curator of Stinky Art Collective   http://www.stinky.com/

From guru at edamame.stinky.com  Wed Sep 20 10:40:40 2000
From: guru at edamame.stinky.com (Alex Chaffee)
Date: Fri Aug  6 17:05:00 2004
Subject: [jdom-interest] getChildren() vs getElements()
In-Reply-To: <39C34F83.3DE08C94@lutris.com>; from brett.mclaughlin@lutris.com on Sat, Sep 16, 2000 at 05:46:27AM -0500
References: <704ECFDA88B3D311B5F000A0C959E5B601FBEB@adobo.c2labs.com> <39C34F83.3DE08C94@lutris.com>
Message-ID: <20000920104040.I5659@edamame.stinky.com>

> getChildElements makes perfect sense, because an Element can easily
> refer to other elements than its own children.

"Easily?"  I think it would be very difficult to interpret
getElements() as returning anything but its own children.

That is, there are a certain number of common-sense first-blush
interpretations about what getElements() would return.  All of these
interpretations would be cleared up with a simple look at the JavaDoc,
but for the sake of those seat-of-the-pants desperadoes who just hack
out code based on "javap org.jdom.Element", then post urgent messages
to jdom-interest after their first compile-time error, we would do
well to examine these interpretations.

Interpretation 1:  getElements() returns the child elements one level deep

This is the correct interpretation and feels natural to anyone who's
used Java collections.

Interpretation 2:  getElements() returns the child elements all levels deep

There is no collection class in java.util, or most anywhere else, that
recurses by default.  In fact, suggestions to add getAllElements() or
equivalent have been dissed by Jason with "just use a recursive
Iterator loop like everyone else" implying that that's The Right Way
to get all elements recursively.  Also, it can be expensive to get all
children, so that's another reason to assume it does not recurse.

Interpretation 3:  getElements() returns the parent element

Yeah, right :-)

Interpretation 4:  getElements() returns all sibling elements

Anyone with a basic concept of tree structure would not expect a child
to refer to its siblings unless through an explicitly-named
getSiblings() or getNextChild() etc.

Are there any other elements that an element could "easily" refer to?

Brett, I hope this helps you work through your phobia of getElements() :-)
I really believe it's not ambiguous, and that its ambiguity is the
only potential problem.

 - A

-- 
Alex Chaffee                       mailto:alex@jguru.com
jGuru - Java News and FAQs         http://www.jguru.com/alex/
Creator of Gamelan                 http://www.gamelan.com/
Founder of Purple Technology       http://www.purpletech.com/
Curator of Stinky Art Collective   http://www.stinky.com/

From pvg at c-c-s.com  Wed Sep 20 12:03:08 2000
From: pvg at c-c-s.com (Peter V. Gadjokov)
Date: Fri Aug  6 17:05:00 2004
Subject: [jdom-interest] getChildren() vs getElements()
Message-ID: <704ECFDA88B3D311B5F000A0C959E5B601FC01@adobo.c2labs.com>



> Defensively: getChildAttributes() was not part of my proposal.  I said
> *IF* we go with getChildElements(), *THEN* we must go with
> getChildAttributes() for consistency.  I meant this as a
> contrapositive subjunctive. 

Yes, it was not your actual proposal, I should have been clearer after the
whole quoting confusion. Nevertheless, if we did go with getChildElements,
getChildAttributes would still be quite questionable. An attribute is not a
child (at least, not in the infoset terminology, if we view the whole thing
as a tree structure, attributes are  definitely nodes and nodes tend to be
children of other nodes in trees, of course) so there is no immediate reason
to have such a method.


-pvg

From kmorehead at idiominc.com  Wed Sep 20 13:46:01 2000
From: kmorehead at idiominc.com (Kem Morehead)
Date: Fri Aug  6 17:05:00 2004
Subject: [jdom-interest] getText with an empty element
Message-ID: <43EA80F14C3ED411841D00508BAE017D1D072E@wal-zulu.idiomtech.com>

I have a feeling this is a stupid question, but I need to be code-complete
in a day so I'm really under the gun. I had jdom working fine, then I had to
switch to the most recent source code and everything went to hell in a
handbasket (so-to-speak).

Here's my question: I have an empty element, which aparently means that
content (in Element.java) is null. When I try to do getText(), instead of
returning null, I get a null pointer exception (because content is null).
What am I supposed to do instead? Which method is it that I need?

I'm really sorry if the answer is obvious.

Thanks in advance!

-------------------------------------------------
Kem Morehead, software engineer
Idiom, Inc. [www.idiominc.com]
781.464.6113
kmorehead@idiominc.com


From brett.mclaughlin at lutris.com  Wed Sep 20 13:58:49 2000
From: brett.mclaughlin at lutris.com (Brett McLaughlin)
Date: Fri Aug  6 17:05:00 2004
Subject: [jdom-interest] BeanMapper
References: <20000920100815.F5659@edamame.stinky.com>
Message-ID: <39C92509.6EA7F0EF@lutris.com>


Alex Chaffee wrote:
> 
> Because there weren't enough XML Data Binding technologies already, I
> just wrote one using JDOM.

Not reading DeveloperWorks at IBM, are you ;-) There's a complete
framework, covered in 4 articles, there. It's based on JDOM and written
by yours truly ;-) Check it out: 

http://www-4.ibm.com/software/developer/library/data-binding1/?dwzone=xml
http://www-4.ibm.com/software/developer/library/data-binding2/?dwzone=xml
http://www-4.ibm.com/software/developer/library/data-binding3/?dwzone=xml


This moves from XML to Java and back.

;-)

-Brett


> 
> org.jdom.contrib.beans.BeanMapper allows you to easily (I'd say
> 'trivially' but that would be taunting the gods) make a JDOM tree from
> an existing JavaBean, and/or instantiate-and-fill one of your JavaBean
> classes based on a JDOM tree.  By default it maps element names and
> property names directly, but you can override that by setting
> mappings; e.g. getFoo() could map to <foo>foovalue</foo> (the default)
> or <bar>foovalue</bar> or <baz baf="foovalue">.
> 
> Usage:
> 
> BeanMapper mapper = new BeanMapper();
> 
> // Converting Bean to JDOM
> Document doc = mapper.toDocument(mybean);
> 
> // Converting JDOM to Bean
> TestBean mybean = mapper.toBean(doc);
> 
> It uses reflection, so it's not super-fast, but it's meant as a quick
> way to get started if you've got a a lot of beans already written and
> want to do XML import/export.
> 
> I seem to have misplaced my CVS password.  Jools, can you please
> contact me about checking this in?  In the meantime, anyone who wants
> to play, please email me privately.
> 
>  - A
> 
> --
> Alex Chaffee                       mailto:alex@jguru.com
> jGuru - Java News and FAQs         http://www.jguru.com/alex/
> Creator of Gamelan                 http://www.gamelan.com/
> Founder of Purple Technology       http://www.purpletech.com/
> Curator of Stinky Art Collective   http://www.stinky.com/
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org

From brett.mclaughlin at lutris.com  Wed Sep 20 14:01:28 2000
From: brett.mclaughlin at lutris.com (Brett McLaughlin)
Date: Fri Aug  6 17:05:00 2004
Subject: [jdom-interest] getChildren() vs getElements()
References: <704ECFDA88B3D311B5F000A0C959E5B601FBEB@adobo.c2labs.com> <39C34F83.3DE08C94@lutris.com> <20000920104040.I5659@edamame.stinky.com>
Message-ID: <39C925A8.7ED830B2@lutris.com>


Alex Chaffee wrote:
> 
> > getChildElements makes perfect sense, because an Element can easily
> > refer to other elements than its own children.
> 
> "Easily?"  I think it would be very difficult to interpret
> getElements() as returning anything but its own children.

I think with XPath, that isn't neccessarily true.

> 
> That is, there are a certain number of common-sense first-blush
> interpretations about what getElements() would return.  All of these
> interpretations would be cleared up with a simple look at the JavaDoc,
> but for the sake of those seat-of-the-pants desperadoes who just hack
> out code based on "javap org.jdom.Element", then post urgent messages

;-)

> to jdom-interest after their first compile-time error, we would do
> well to examine these interpretations.
> 
> Interpretation 1:  getElements() returns the child elements one level deep
> 
> This is the correct interpretation and feels natural to anyone who's
> used Java collections.
> 
> Interpretation 2:  getElements() returns the child elements all levels deep
> 
> There is no collection class in java.util, or most anywhere else, that
> recurses by default.  In fact, suggestions to add getAllElements() or
> equivalent have been dissed by Jason with "just use a recursive
> Iterator loop like everyone else" implying that that's The Right Way
> to get all elements recursively.  Also, it can be expensive to get all
> children, so that's another reason to assume it does not recurse.
> 
> Interpretation 3:  getElements() returns the parent element
> 
> Yeah, right :-)
> 
> Interpretation 4:  getElements() returns all sibling elements
> 
> Anyone with a basic concept of tree structure would not expect a child
> to refer to its siblings unless through an explicitly-named
> getSiblings() or getNextChild() etc.
> 
> Are there any other elements that an element could "easily" refer to?
> 
> Brett, I hope this helps you work through your phobia of getElements() :-)
> I really believe it's not ambiguous, and that its ambiguity is the
> only potential problem.

I have less of a phobia for getElements() than for getChildren(),
certainly. But thanks for the help, you can bill me ;-) My biggest
concern is with XPath. But if people are OK with that, and really
against getChildElements(), I can live with getElements() much more
easily than getChildren().

-=Brett

> 
>  - A
> 
> --
> Alex Chaffee                       mailto:alex@jguru.com
> jGuru - Java News and FAQs         http://www.jguru.com/alex/
> Creator of Gamelan                 http://www.gamelan.com/
> Founder of Purple Technology       http://www.purpletech.com/
> Curator of Stinky Art Collective   http://www.stinky.com/

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org

From jpeck at stshotelnet.com  Wed Sep 20 13:15:05 2000
From: jpeck at stshotelnet.com (Jason Peck)
Date: Fri Aug  6 17:05:00 2004
Subject: [jdom-interest] Element.getText() bug
Message-ID: <001901c0233f$7777ddf0$690c010a@stshotelnet.com>

I think I have found a bug in the 9/17/00 build of JDOM.

When calling the getText() method of an element that has no data (ie.
<user></user> ), the Element.getText() method throws a NullPointer
exception.  However, if for some funny reason, I output the xml to screen
using XMLOutputter first, the exception is not thrown.  I saw in a previous
post that a change was made to XMLOutputter.output to change <user></user>
to <user/> if no data is found between.  Shouldn't getText() either return
NULL or "" if no text is found??

Thanks,
Jason


From mengelhart at earthtrip.com  Wed Sep 20 15:17:25 2000
From: mengelhart at earthtrip.com (Michael Engelhart)
Date: Fri Aug  6 17:05:00 2004
Subject: [jdom-interest] BeanMapper
Message-ID: <200009200935.e8K9ZkE14521@sm3.texas.rr.com>

> Not reading DeveloperWorks at IBM, are you ;-) There's a complete
> framework, covered in 4 articles, there. It's based on JDOM and written
> by yours truly ;-) Check it out:
>

There's also Castor that does this although it's pretty limiting in how it  
generates the XML as far as using attributes vs. elements.

Mike

From brett.mclaughlin at lutris.com  Wed Sep 20 15:33:20 2000
From: brett.mclaughlin at lutris.com (Brett McLaughlin)
Date: Fri Aug  6 17:05:00 2004
Subject: [jdom-interest] Element.getText() bug
References: <001901c0233f$7777ddf0$690c010a@stshotelnet.com>
Message-ID: <39C93B30.DFA8188A@lutris.com>


Jason Peck wrote:
> 
> I think I have found a bug in the 9/17/00 build of JDOM.
> 
> When calling the getText() method of an element that has no data (ie.
> <user></user> ), the Element.getText() method throws a NullPointer
> exception.  However, if for some funny reason, I output the xml to screen
> using XMLOutputter first, the exception is not thrown.  I saw in a previous
> post that a change was made to XMLOutputter.output to change <user></user>
> to <user/> if no data is found between.  Shouldn't getText() either return
> NULL or "" if no text is found??


I just fixed this yesterday - try the latest from CVS.

Thanks,
Brett

> 
> Thanks,
> Jason
> 
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org

From brett.mclaughlin at lutris.com  Wed Sep 20 15:33:57 2000
From: brett.mclaughlin at lutris.com (Brett McLaughlin)
Date: Fri Aug  6 17:05:00 2004
Subject: [jdom-interest] getText with an empty element
References: <43EA80F14C3ED411841D00508BAE017D1D072E@wal-zulu.idiomtech.com>
Message-ID: <39C93B55.4D53E8ED@lutris.com>


Kem Morehead wrote:
> 
> I have a feeling this is a stupid question, but I need to be code-complete
> in a day so I'm really under the gun. I had jdom working fine, then I had to
> switch to the most recent source code and everything went to hell in a
> handbasket (so-to-speak).
> 
> Here's my question: I have an empty element, which aparently means that
> content (in Element.java) is null. When I try to do getText(), instead of
> returning null, I get a null pointer exception (because content is null).
> What am I supposed to do instead? Which method is it that I need?

Nope - I just fixed this yesterday (it was a bug) so try the latest from
CVS.

Thanks,
Brett

> 
> I'm really sorry if the answer is obvious.
> 
> Thanks in advance!
> 
> -------------------------------------------------
> Kem Morehead, software engineer
> Idiom, Inc. [www.idiominc.com]
> 781.464.6113
> kmorehead@idiominc.com
> 
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org

From omenred at yahoo.com  Wed Sep 20 16:12:34 2000
From: omenred at yahoo.com (Omen Red)
Date: Fri Aug  6 17:05:00 2004
Subject: [jdom-interest] getChildren() vs getElements() 
Message-ID: <20000920231234.8013.qmail@web2106.mail.yahoo.com>

What is the current score in battle getChildren()
against getElement() ? Is there any way to get this information?

__________________________________________________
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/

From pvg at c-c-s.com  Wed Sep 20 18:35:21 2000
From: pvg at c-c-s.com (Peter V. Gadjokov)
Date: Fri Aug  6 17:05:00 2004
Subject: [jdom-interest] getChildren() vs getElements() 
Message-ID: <704ECFDA88B3D311B5F000A0C959E5B601FC0C@adobo.c2labs.com>

"Achilles' baneful wrath resound, O Goddess, that imposed
infinite sorrows on the Greeks, and many brave soul loosed
from breasts heroic; sent them far to that invisible cave
that no light comforts; and their limbs to dogs and vultures gave:
to all which Jove's will gave effect; from whom first strife begun
betwixt Atrides, king of men, and Thetis' godlike son."

It's hard to tell what the score is. Recently, on All Of My Elements, we've
discussed a number of approaches. 


Wu-tang style:

Keep things as they are, getChild stays as it is. It's short and it's sweet
and we know it complete. Major proponent, I think, is Jason "Uncarved Block"
Hunter, who believes this API speeds his journey down the eightfold path and
helps him write books. Major opponent is Brett who wants to burn such
spec-less heresy in effigy and dance by the flame.  


I got your element right here, pal:

Change getChild and co to getElement/getElements, potentially make the
'child' methods for adding and removing stuff add and remove things that the
spec actually calls children (element, pi, cdata, and the like, but not
attributes). Major proponent is Alex "There's no other Element but Zuul"
Chaffee, Jason has expressed misgivings about the havoc this wreaks upon his
beloved getChildTextTrim.


Sweet childElement of mine:

This one would change getChild to getChildElement and so on. Part of the
motivation is spec-compliance (and clarity-through-verbosity) but it's not
quite certain if this approach would also mean replacing the content methods
with methods that talk about children. Major proponent is Brett
"Spec-Thumpin'" McLaughlin.


Peter "V. is for Verbal" Gadjokov

-pvg

P.S. All misrepresentations above are in jest, in error or both.


From sligade at claravista.com  Wed Sep 20 06:21:03 2000
From: sligade at claravista.com (Ligade, Shailesh)
Date: Fri Aug  6 17:05:00 2004
Subject: [jdom-interest] DTD file and validation
Message-ID: <61AFDCD264A7D211A09300105AC8A2838BA6C9@mail.claravista.com>

Hello all,

I have a basic question. I could create a xml file using JDOM that is
namespace aware. The problem is that this file is not happy with the dtd i
have generated with xml spy 3.0 when I try to read it with validating
parser.

In other words, xml spy is happy with my dtd but not my parser xcrces (which
I got along with JDOM b4)

-----------------------------------------------------------------------
my file looks like this:

<?xml version="1.0" encoding="ISO-8859-1"?>
<!--DOCTYPE KODetail SYSTEM "http://laestrella/KODetail.dtd"-->
<!DOCTYPE KODetail SYSTEM "c:\ATG\Dynamo4.5.0\projects\jhtml\KODetail.dtd">


<KODetail>
  <iPower:DocID
xmlns:iPower="http://laestrealla/iPower">1000336</iPower:DocID>
  <iPower:Title>Jason - XML</iPower:Title>
</KODetail>

----------------------------------------------------------------------
and my dtd looks like this:

<!ELEMENT KODetail (
iPower:DocID,
iPower:Title
) >

<!ELEMENT iPower:DocID (#PCDATA)  >
<!ATTLIST iPower:DocID xmlns:iPower CDATA #REQUIRED >
<!ELEMENT iPower:Title (#PCDATA)  >

I have even removed attribute line from DocID but no help.

What I am doing wrong? I found very contradicting things regarding how to
construct the DTD,

some messages told me to add namespace prefix as a part of element in DTD
(JAVA and XML book example has this one)
while others asked me to remove that. Also, xmlns, is that a attribute in
DTD or not. I got contradictory views on that one too.

Obviously parsers make lot of difference! SO this question is how to make
the parser 'xcrces' happy?

Thanks in advance.

Shailesh

From chheda at oak-grove-systems.com  Wed Sep 20 08:57:22 2000
From: chheda at oak-grove-systems.com (Bhavesh Chheda)
Date: Fri Aug  6 17:05:00 2004
Subject: [jdom-interest] bug in getText() ??
Message-ID: <27B117C36C3875A04FB403D0@www.oak-grove-systems.com>

hi, getText() method in Element class threw a NullPointerException when i
tried to get text from debug_info element in the xml shown below.

I dont see any problem with the xml shown above and also the instance of
element debug_info was not null. when i add some text in the debug_info
element it works fine but when i remove it throws an NPE.
<?xml version="1.0" encoding="UTF-8"?>
<response><result_code>200</result_code><user_message>OK</user_message>
<debug_info
/><return_values><authentication_token>Token-1</authentication_token>
</return_values></response>

I checked out code yesterday i.e Sep 19 and CVS version of Element.java was
1.28.

In the getText() somehow varible content is being set to null. This is
causing getContent(), getTextTrim() methods also to throw NPE. I added a
line
	if (content == null) return null;

in the first line of getTextMethod(). And after that i seemed to work fine.
:)
--bhavesh


From vreddy at whn.com  Wed Sep 20 13:20:25 2000
From: vreddy at whn.com (Vamshi Reddy)
Date: Fri Aug  6 17:05:01 2004
Subject: [jdom-interest] RE: no method: Element.setName(String)
In-Reply-To: <213B28F4301DD411A81300508B0CCCDAB5BB95@WHNEXG01.hq.whn.com>
Message-ID: <213B28F4301DD411A81300508B0CCCDA0810E7@WHNEXG01.hq.whn.com>

Travers,

I had the same question. Brett said that it was intensionally removed. I
found an alternate solution to this problem although it can be
memory-intensive if the element/tree is large.

This message was never posted? See below. Hope this helps.

Vamshi Reddy

RE: Class org.jdom.Element

methods: setName(string), setName(string, string)

These methods are in current JavaDoc drop:  jdom-b3_docs(168k). Jason
replied to the mail (sorry for sending it direct) by saying that these
methods were intentionally removed. If a default constructor Element() is
available then how is it possible to set the name after creating and setting
all the required nodes?

If you try to take a child element from another parent element and add it to
a newly created root element, an exception is thrown as this is not allowed.
A way around this is to  clone the required element and add it to the new
root element. If all you wanted to do is to perform an in-line update to the
current document and send it to an output stream.


 Element oldChild =
(Element)document.getRootElement().getChild("Child").clone();
 List oldRootAttributes = document.getRootElement().getAttributes(); //save
all old attribs
 doc = null; //dump the old document or ...

Element newRootElement = new Element("NewRoot");
  newElement.setAttributes(oldRootAttributes); //or individually add:
newElement.setAttribute("name", "value")
	.....more code......

document = new Document(newRootElement, new
DocType(newRootElement.getName(), "external.dtd"));

All this can be avoided by setName(). I modified the source at the time I
needed it but removed it after I received the mail to avoid future errors as
the updates occur.

Please suggest any better ways of getting around this.

Thanks,

vr

-----Original Message-----
From: jdom-interest-admin@jdom.org
[mailto:jdom-interest-admin@jdom.org]On Behalf Of
jdom-interest-request@jdom.org
Sent: Tuesday, September 19, 2000 11:02 PM
To: jdom-interest@jdom.org
Subject: jdom-interest digest, Vol 1 #246 - 13 msgs


Send jdom-interest mailing list submissions to
	jdom-interest@jdom.org

To subscribe or unsubscribe via the World Wide Web, visit
	http://lists.denveronline.net/mailman/listinfo/jdom-interest
or, via email, send a message with subject or body 'help' to
	jdom-interest-request@jdom.org

You can reach the person managing the list at
	jdom-interest-admin@jdom.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of jdom-interest digest..."


Today's Topics:

  1. Re: DTD im XML-File and Element.getContent() (Marcus Breig)
  2. no method: Element.setName(String). Why? (Travers Waker)
  3. Re: Off Topic - XSL (Xalan) question (Aidan Killian)
  4. Problem with DTD (Steven Smith)
  5. static data needs to be thread data for multithreaded application
 s (Nick Reeves)
  6. XMLOutputter - setExpandEmptyElements(true) not functioning
 properly. (kendrick@us.ibm.com)
  7. [BUG] (Wolfgang Werner)
  8. Re: [BUG] (Brett McLaughlin)
  9. Re: XMLOutputter - setExpandEmptyElements(true) not
 functioningproperly. (Brett McLaughlin)
  10. Re: DTD im XML-File and Element.getContent() (Brett McLaughlin)

--__--__--

Message: 1
Date: Tue, 19 Sep 2000 09:01:39 +0200
From: Marcus Breig <mbreig@i2ag.de>
Reply-To: mbreig@i2ag.de
Organization: IQUADRAT AG, Wuppertal
To: Brett McLaughlin <brett.mclaughlin@lutris.com>
CC: JDOM-Liste <jdom-interest@jdom.org>
Subject: Re: [jdom-interest] DTD im XML-File and Element.getContent()
boundary="------------3EBF27EA2DD375AE51700D86"

Dies ist eine mehrteilige Nachricht im MIME-Format.
--------------3EBF27EA2DD375AE51700D86
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Brett,

the XML-File (with DTD) in the attachment...

Marcus

Brett McLaughlin schrieb:

> Marcus Breig wrote:
> > My problem: my sample XML-File contains a DTD for
> > defining my XML-language. In this case the method
> > Element.getContent() always returns an empty string.
>
> Can you post your XML document? I think I know what this is, but I want
> to make sure.
>
> Thanks
> Brett

--------------3EBF27EA2DD375AE51700D86
Content-Type: text/xml; charset=iso-8859-1;
 name="users.xml"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline;
 filename="users.xml"

<?xml version='1.0' encoding="ISO-8859-1" standalone="yes" ?>

<!DOCTYPE users [

	<!ELEMENT users (groups, user+) >

		<!ELEMENT groups (group)+ >
			<!ELEMENT group (members, accessRights, commandRights)+ >
			<!ATTLIST group name CDATA #REQUIRED >
				<!ELEMENT members (member)+ >
					<!ELEMENT member (#PCDATA) >
				<!ELEMENT accessRights (table)+ >
					<!ELEMENT table EMPTY >
					<!ATTLIST table name CDATA #REQUIRED >
					<!ATTLIST table canRead (true|false) "false" >
					<!ATTLIST table canWrite (true|false) "false" >
				<!ELEMENT commandRights (tableCmds)+  >
					<!ELEMENT tableCmds (command)+ >
					<!ATTLIST tableCmds tablename CDATA #REQUIRED >
						<!ELEMENT command EMPTY >
						<!ATTLIST command name CDATA #REQUIRED >
						<!ATTLIST command allowed (true|false) "false" >
		<!ELEMENT user (config, accessRights*, commandRights*, information*) >
			<!ELEMENT config (nickname, top, store) >
				<!ELEMENT nickname (#PCDATA) >
				<!ELEMENT top (#PCDATA) >
				<!ELEMENT store (#PCDATA) >
			<!ELEMENT information (nachname, vorname, anschrift, plz, ort, telefon,
telefax, email) >
				<!ELEMENT nachname (#PCDATA) >
				<!ELEMENT vorname (#PCDATA) >
				<!ELEMENT anschrift (#PCDATA) >
				<!ELEMENT plz (#PCDATA) >
				<!ELEMENT ort (#PCDATA) >
				<!ELEMENT telefon (#PCDATA) >
				<!ELEMENT telefax (#PCDATA) >
				<!ELEMENT email (#PCDATA) >
]>

<!-- hier folgt die Beschreibung der Benutzergruppen, Zugriffsrechte und
Benutzer -->

<users>

	<groups>

		<group name="projektleiter">
			<members>
				<member>MB</member>
				<member>RS</member>
			</members>
			<accessRights>
				<table name="adressen" canRead="true" canWrite="true" />
				<table name="dokumente" canRead="true" canWrite="true" />
				<table name="projekte" canRead="true" canWrite="true" />
			</accessRights>
			<commandRights>
				<tableCmds tablename="adressen">
					<command name="new" allowed="true" />
					<command name="edit" allowed="true" />
					<command name="delete" allowed="true" />
					<command name="copy" allowed="true" />
				</tableCmds>
				<tableCmds tablename="dokumente">
					<command name="new" allowed="true" />
					<command name="edit" allowed="true" />
					<command name="export" allowed="true" />
					<command name="import" allowed="true" />
					<command name="lock" allowed="true" />
					<command name="copy" allowed="true" />
					<command name="release" allowed="true" />
					<command name="delete" allowed="true" />
					<command name="view" allowed="true" />
				</tableCmds>
				<tableCmds tablename="projekte">
					<command name="new" allowed="true" />
					<command name="edit" allowed="true" />
					<command name="delete" allowed="true" />
					<command name="copy" allowed="true" />
				</tableCmds>
			</commandRights>
		</group>
	</groups>


	<user>
		<config>
			<nickname>SM</nickname>
			<top>/</top>
			<store>/ENTWICKLUNG/SOURCE/SM</store>
		</config>
		<information>
			<nachname>Meisner</nachname>
			<vorname>Hans Georg-Stefan Andreas Bernhard</vorname>
			<anschrift>L?nener Str. 31</anschrift>
			<plz>40472</plz>
			<ort>D?sseldorf</ort>
			<telefon>0211-6011976</telefon>
			<telefax>-</telefax>
			<email>sm@i2ag.de</email>
		</information>
	</user>
	<user>
		<config>
			<nickname>ML</nickname>
			<top>/</top>
			<store>/ML</store>
		</config>
		<information>
			<nachname>Loges</nachname>
			<vorname>Marc</vorname>
			<anschrift>-</anschrift>
			<plz>00000</plz>
			<ort>Wuppertal</ort>
			<telefon>0202-???</telefon>
			<telefax>-</telefax>
			<email>ml@kbld.de</email>
		</information>
	</user>
</users>
--------------3EBF27EA2DD375AE51700D86--


--__--__--

Message: 2
From: "Travers Waker" <traversw@innoforge.co.za>
To: <jdom-interest@jdom.org>
Date: Tue, 19 Sep 2000 10:58:54 +0200
charset="iso-8859-1"
Subject: [jdom-interest] no method: Element.setName(String). Why?

Hi all.

I've found a need for the following method of the Element class (but it
doesn't exist):

 Element.setName(String name)

Is there a technical reason why this method can't exist in the current Jdom?

At the moment I'm getting around this limitations as follows:
use Element.getCopy(String name) to create a clone (deep copy) of the
element.  This is pretty wasteful, because I don't need the original element
tree any more and would liek to reuse it with a new root element name
instread of doing expensive deep copies.

In case you're interested in where I'm applying this: It's to represent
request and response message pairs.  In most cases, the XML request message
is exactly the same as the response message except for:
1. The root element is called {something}ResponseMessage instead of
{something}RequestMessage.
2. The addition of a  ResponseCode child element.
3. The addition of a ResponseMessage child element.

2 and 3 are easy to do with Jdom, but changing the name of the root element
is not.

Thanks for any help or info.

Travers



--__--__--

Message: 3
Date: Tue, 19 Sep 2000 10:50:15 +0100
From: Aidan Killian <aidan@concordianet.com>
Organization: Concordia Net, Inc.
To: jdom-interest@jdom.org, VanDoorenD@icfg.com
Subject: [jdom-interest] Re: Off Topic - XSL (Xalan) question

jdom-interest-request@jdom.org wrote:

>
> From: "Van Dooren, Damian" <VanDoorenD@icfg.com>
> To: "JDOM (E-mail)" <jdom-interest@jdom.org>
> Date: Mon, 18 Sep 2000 11:43:32 -0400
> charset="iso-8859-1"
> Subject: [jdom-interest] Off Topic - XSL (Xalan) question
>
> ...
>
> org.apache.xalan.xslt.XSLProcessorException: The reference to entity
> "subaction"  must end with the ';' delimiter.
>
> This is the line it is dying on:
>
> <a
>
href='http://localhost/login/ActionServer?action=loadpage&subaction=html&fil
> eName=client-inquiry.html'>Client Inquiry</a>
>
> I've included the XSL and have commented out the offending line. If
someone
> could point out what I've done wrong I would greatly appreciated it.
>
> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
>                 version="1.0"
> >
>   <xsl:template match="/">
>     <html>
>       <head><title>Main Menu</title></head>
>
>       <body bgcolor="#FFFFFF">
>         <h2>Main Menu</h2>
>         <p>
> <!-- Why doesn't it like this line?
>         <a
>
href='http://localhost/login/ActionServer?action=loadpage&subaction=html&fil
> eName=client-inquiry.html'>Client Inquiry</a>
> -->
>         </p>
>       </body>
>     </html>
>   </xsl:template>
> </xsl:stylesheet>
>
> Hi Damian,

    The parameter separator in the URL is being interpreted as an entity
reference open; an XML parser sees '&subaction' and says where is the
entity reference close (';').

    You need to escape the '&'s using '&amp;'s as follows (line wrapped by
me):

href='http://localhost/login/ActionServer?action=loadpage&amp;
subaction=html&amp;fileName=client-inquiry.html'>

Regards,
    Aidan Killian



--__--__--

Message: 4
From: "Steven Smith" <ssmith@neonsys.com>
To: jdom-interest@jdom.org
Date: Tue, 19 Sep 2000 10:50:59 -0500
Boundary="0__=Qc36xzptzVvMSf0Gfs5kxuBCf33gOVwbUupCcL4uzjFlLveJqQnqLcN1"
Subject: [jdom-interest] Problem with DTD

--0__=Qc36xzptzVvMSf0Gfs5kxuBCf33gOVwbUupCcL4uzjFlLveJqQnqLcN1
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline



(Embedded image moved to file: pic22322.pcx)   Steven Smith @ NEON
09/19/2000 10:50 AM


My apologies for the most basis of questions....

I have a very simple XML document that I'm trying to manipulate with JDOM.
The DOCTYPE is as follows:

     <!DOCTYPE test SYSTEM "test.dtd">

When I attempt to construct a Document via SAXBuilder.build(), I get the
following exception:

     org.jdom.JDOMException: File "test.dtd" not found.: Error on line 0:
File "test.dtd" not found.

I am running my program from the command prompt in Windows 2000 and
test.dtd is in my current directory.  I don't understand why the dtd can't
be located.

Any help would be most appreciated.

Thanks,

Steven

--0__=Qc36xzptzVvMSf0Gfs5kxuBCf33gOVwbUupCcL4uzjFlLveJqQnqLcN1
Content-type: application/octet-stream;
	name="pic22322.pcx"
Content-Disposition: attachment; filename="pic22322.pcx"
Content-transfer-encoding: base64

CgUBCAAAAAAtADMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAABLgABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAADYD8wPxg/DDw/YD8wPxg/DDw/YD8wPxg/DDw/YD8wPxg/DDw/CDw4PDtUP
yw/FD8MPDw8ODw4PDtUPyg/FD8MPDw4PDg8ODw7UD8oPxQ/DDw8PDg8ODw4PDtQPyg/FD8IPDw4P
Dg8ODw7UD8oPxQ/DDw8PDg8ODw4PDsgPxA7OD8cPww/CD8IPDg8ODw7ID8YOzQ/HD8MPwg/DDw4P
DsgPyA7ND8YPww/CD84PyA7ND8YPww/CD84PyA7ND8YPww/CD84PyA7ND8YPww/CD88Pxg7ND8cP
ww/CD9APxA7OD8cPww/CD9gPxA8ODA4MyA/ED8IP2A/DDw4MDgwODMcPxA/CD9gPwg8ODA4MDgwO
DMcPww/CD9gPwg8MDgwODA4MDscPww/CD9gPwg8ODA4MDgwODMcPww/CD9gPwg8MDgwODA4MDscP
ww/CD9gPww8MDgwODA7HD8QPwg/YD8QPDA4MDsgPxA/CD9gPzA/GD8MPD9gPzA/GD8MPD9gPzA/G
D8MPD9gPzA/GD8MPD9gPzA/EDMQPwg/YD8sPxgzDD8IP2A/KD8cMDMMPD9gPyg/HDAzDDw/YD8oP
xwwMww8P2A/KD8cMDMMPD9gPyw/GDMMPwg/YD8wPxAzED8IP2A/MD8YPww8P2A/MD8YPww8P2A/M
D8YPww8P2A/MD8YPww8P2A/MD8YPww8P2A/MD8YPww8P2A/MD8YPww8P2A/MD8MPxATCDw/YD8wP
wg/FBATCD9gPzA8PxQTDBA/YD8wPD8UEwwQP2A/MDw/FBMMED9gPzA8PxQTDBA/YD8wPwg/FBATC
D9gPzA/DD8QEwg8PDAAAAIAAAACAAICAAAAAgIAAgACAgICAgMDAwP8AAAD/AP//AAAA//8A/wD/
/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==

--0__=Qc36xzptzVvMSf0Gfs5kxuBCf33gOVwbUupCcL4uzjFlLveJqQnqLcN1--


--__--__--

Message: 5
From: Nick Reeves <Nick.Reeves@gtl.com>
To: "'jdom-interest@jdom.org'" <jdom-interest@jdom.org>
Date: Tue, 19 Sep 2000 15:40:03 +0100
charset="iso-8859-1"
Subject: [jdom-interest] static data needs to be thread data for
multithreaded application
s

Let me make clear first of all I am not asking for individual JDOM Objects
to be thread safe. I fully agree that the caller should be responsible for
this, following the example of the Java Collections API.

However where the class has hidden static data (such as
Namespace.namespaces)the class must be responsible for making access to this
thread safe otherwise multithreaded applications such as your typical Web or
EJB case, have no choice but to single thread all use of the JDOM packages
:(. This would lead to appalling performance in any realistic use.

At present multihreaded use of Namespace.getNamespace even indirectly (eg by
importing files in different threads) will cause random failures with
ConcurrentModificationException.


--__--__--

Message: 6
From: kendrick@us.ibm.com
To: jdom-interest@jdom.org
Date: Tue, 19 Sep 2000 13:13:44 -0400
Subject: [jdom-interest] XMLOutputter - setExpandEmptyElements(true) not
functioning
properly.



I am seeing my empty elements (content of an empty String) outputted in the
shorthand format (<tagName />) even after I issued
setExpandEmptyElements(true).  I traced the code in XMLOutputter.
printElement() to:

     ...
     if (empty) {
          // Simply close up
          if (!expandEmptyElements) {
               out.write(" />");
          } else {
               out.write("></");
               out.write(element.getQualifiedName());
               out.write(">");
          }
          maybePrintln(out);
     } else if (stringOnly) {
          // Print the tag  with String on same line
          // Example: <tag name="value">content</tag>
          // Also handle "" being added to content
          String elementText = element.getText();
          if ((elementText != null) && (!elementText.equals(""))) {
               out.write(">");
               out.write(escapeElementEntities(element.getText()));
               out.write("</");
               out.write(element.getQualifiedName());
               out.write(">");
          } else {
==========>
== here ==>         out.write(" />");
==========>
          }
          maybePrintln(out);
     } else {
     ...

Apparently the check for expandEmptyElements needs to occur here as well.

Sincerely,
Shannon

IBM e-business Integration Services
3200 Windy Hill Road - Atlanta, GA 30332 - WG06B
Phone: 770-835-7672 T/L 445   FAX: 770-835-6479
Internet: kendrick@us.ibm.com



--__--__--

Message: 7
From: "Wolfgang Werner" <wwerner@picturesafe.de>
To: "Jdom-Interest@Jdom. Org" <jdom-interest@jdom.org>
Date: Tue, 19 Sep 2000 22:15:44 +0200
charset="iso-8859-1"
Subject: [jdom-interest] [BUG]

Hello,

I think I found a very small Bug in Element.java:

If you create an Element without textual content, e.g

	Element e = new Element("test");

and put it into an Document, the function

	e.getText()

on this element fails with a NullPointerException due to the
shortcut in the first lines: Access to content.

A short look at the code reveals that other funtions do a
test for this before atempting to access the content list.

Did I miss something? I tested this on the CVS code from
(i think) two days ago.

Thanks,

	Wolfgang Werner

--__--__--

Message: 8
Date: Tue, 19 Sep 2000 19:27:45 -0500
From: Brett McLaughlin <brett.mclaughlin@lutris.com>
Organization: Lutris Technologies
CC: "Jdom-Interest@Jdom. Org" <jdom-interest@jdom.org>
Subject: Re: [jdom-interest] [BUG]



Wolfgang Werner wrote:
>
> Hello,
>
> I think I found a very small Bug in Element.java:
>
> If you create an Element without textual content, e.g
>
>         Element e = new Element("test");
>
> and put it into an Document, the function
>
>         e.getText()
>
> on this element fails with a NullPointerException due to the
> shortcut in the first lines: Access to content.
>
> A short look at the code reveals that other funtions do a
> test for this before atempting to access the content list.
>
> Did I miss something? I tested this on the CVS code from
> (i think) two days ago.

I fixed this ... give it a try now with the latest from CVS.

-Brett

>
> Thanks,
>
>         Wolfgang Werner
> _______________________________________________
> To control your jdom-interest membership:
>
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com

--
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc.
1200 Pacific Avenue, Suite 300
Santa Cruz, CA 95060 USA
http://www.lutris.com
http://www.enhydra.org

--__--__--

Message: 9
Date: Tue, 19 Sep 2000 19:30:10 -0500
From: Brett McLaughlin <brett.mclaughlin@lutris.com>
Organization: Lutris Technologies
CC: jdom-interest@jdom.org
Subject: Re: [jdom-interest] XMLOutputter - setExpandEmptyElements(true) not
functioningproperly.



kendrick@us.ibm.com wrote:
>
> I am seeing my empty elements (content of an empty String) outputted in
the
> shorthand format (<tagName />) even after I issued
> setExpandEmptyElements(true).  I traced the code in XMLOutputter.
> printElement() to:
>
>      ...
>      if (empty) {
>           // Simply close up
>           if (!expandEmptyElements) {
>                out.write(" />");
>           } else {
>                out.write("></");
>                out.write(element.getQualifiedName());
>                out.write(">");
>           }
>           maybePrintln(out);
>      } else if (stringOnly) {
>           // Print the tag  with String on same line
>           // Example: <tag name="value">content</tag>
>           // Also handle "" being added to content
>           String elementText = element.getText();
>           if ((elementText != null) && (!elementText.equals(""))) {
>                out.write(">");
>                out.write(escapeElementEntities(element.getText()));
>                out.write("</");
>                out.write(element.getQualifiedName());
>                out.write(">");
>           } else {
> ==========>
> == here ==>         out.write(" />");
> ==========>
>           }
>           maybePrintln(out);
>      } else {
>      ...
>
> Apparently the check for expandEmptyElements needs to occur here as well.

Yup. Just fixed it - try it now, and let me know if it works.

Thanks,
Brett

>
> Sincerely,
> Shannon
>
> IBM e-business Integration Services
> 3200 Windy Hill Road - Atlanta, GA 30332 - WG06B
> Phone: 770-835-7672 T/L 445   FAX: 770-835-6479
> Internet: kendrick@us.ibm.com
>
> _______________________________________________
> To control your jdom-interest membership:
>
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com

--
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc.
1200 Pacific Avenue, Suite 300
Santa Cruz, CA 95060 USA
http://www.lutris.com
http://www.enhydra.org

--__--__--

Message: 10
Date: Tue, 19 Sep 2000 19:32:17 -0500
From: Brett McLaughlin <brett.mclaughlin@lutris.com>
Organization: Lutris Technologies
CC: JDOM-Liste <jdom-interest@jdom.org>
Subject: Re: [jdom-interest] DTD im XML-File and Element.getContent()



Marcus Breig wrote:
>
> Hi Brett,
>
> the XML-File (with DTD) in the attachment...

Ahhh, yes. We have some known problems with inline DOCTYPE definitions -
I will work on this soon, and report the fix. Thanks!

-Brett

>
> Marcus
>
> Brett McLaughlin schrieb:
>
> > Marcus Breig wrote:
> > > My problem: my sample XML-File contains a DTD for
> > > defining my XML-language. In this case the method
> > > Element.getContent() always returns an empty string.
> >
> > Can you post your XML document? I think I know what this is, but I want
> > to make sure.
> >
> > Thanks
> > Brett
>
>   ------------------------------------------------------------------------
> <?xml version='1.0' encoding="ISO-8859-1" standalone="yes" ?>
>
> <!DOCTYPE users [
>
>         <!ELEMENT users (groups, user+) >
>
>                 <!ELEMENT groups (group)+ >
>                         <!ELEMENT group (members, accessRights,
commandRights)+ >
>                         <!ATTLIST group name CDATA #REQUIRED >
>                                 <!ELEMENT members (member)+ >
>                                         <!ELEMENT member (#PCDATA) >
>                                 <!ELEMENT accessRights (table)+ >
>                                         <!ELEMENT table EMPTY >
>                                         <!ATTLIST table name CDATA
#REQUIRED >
>                                         <!ATTLIST table canRead
(true|false) "false" >
>                                         <!ATTLIST table canWrite
(true|false) "false" >
>                                 <!ELEMENT commandRights (tableCmds)+  >
>                                         <!ELEMENT tableCmds (command)+ >
>                                         <!ATTLIST tableCmds tablename
CDATA #REQUIRED >
>                                                 <!ELEMENT command EMPTY >
>                                                 <!ATTLIST command name
CDATA #REQUIRED >
>                                                 <!ATTLIST command allowed
(true|false) "false" >
>                 <!ELEMENT user (config, accessRights*, commandRights*,
information*) >
>                         <!ELEMENT config (nickname, top, store) >
>                                 <!ELEMENT nickname (#PCDATA) >
>                                 <!ELEMENT top (#PCDATA) >
>                                 <!ELEMENT store (#PCDATA) >
>                         <!ELEMENT information (nachname, vorname,
anschrift, plz, ort, telefon, telefax, email) >
>                                 <!ELEMENT nachname (#PCDATA) >
>                                 <!ELEMENT vorname (#PCDATA) >
>                                 <!ELEMENT anschrift (#PCDATA) >
>                                 <!ELEMENT plz (#PCDATA) >
>                                 <!ELEMENT ort (#PCDATA) >
>                                 <!ELEMENT telefon (#PCDATA) >
>                                 <!ELEMENT telefax (#PCDATA) >
>                                 <!ELEMENT email (#PCDATA) >
> ]>
>
> <!-- hier folgt die Beschreibung der Benutzergruppen, Zugriffsrechte und
Benutzer -->
>
> <users>
>
>         <groups>
>
>                 <group name="projektleiter">
>                         <members>
>                                 <member>MB</member>
>                                 <member>RS</member>
>                         </members>
>                         <accessRights>
>                                 <table name="adressen" canRead="true"
canWrite="true" />
>                                 <table name="dokumente" canRead="true"
canWrite="true" />
>                                 <table name="projekte" canRead="true"
canWrite="true" />
>                         </accessRights>
>                         <commandRights>
>                                 <tableCmds tablename="adressen">
>                                         <command name="new" allowed="true"
/>
>                                         <command name="edit"
allowed="true" />
>                                         <command name="delete"
allowed="true" />
>                                         <command name="copy"
allowed="true" />
>                                 </tableCmds>
>                                 <tableCmds tablename="dokumente">
>                                         <command name="new" allowed="true"
/>
>                                         <command name="edit"
allowed="true" />
>                                         <command name="export"
allowed="true" />
>                                         <command name="import"
allowed="true" />
>                                         <command name="lock"
allowed="true" />
>                                         <command name="copy"
allowed="true" />
>                                         <command name="release"
allowed="true" />
>                                         <command name="delete"
allowed="true" />
>                                         <command name="view"
allowed="true" />
>                                 </tableCmds>
>                                 <tableCmds tablename="projekte">
>                                         <command name="new" allowed="true"
/>
>                                         <command name="edit"
allowed="true" />
>                                         <command name="delete"
allowed="true" />
>                                         <command name="copy"
allowed="true" />
>                                 </tableCmds>
>                         </commandRights>
>                 </group>
>         </groups>
>
>         <user>
>                 <config>
>                         <nickname>SM</nickname>
>                         <top>/</top>
>                         <store>/ENTWICKLUNG/SOURCE/SM</store>
>                 </config>
>                 <information>
>                         <nachname>Meisner</nachname>
>                         <vorname>Hans Georg-Stefan Andreas
Bernhard</vorname>
>                         <anschrift>L?nener Str. 31</anschrift>
>                         <plz>40472</plz>
>                         <ort>D?sseldorf</ort>
>                         <telefon>0211-6011976</telefon>
>                         <telefax>-</telefax>
>                         <email>sm@i2ag.de</email>
>                 </information>
>         </user>
>         <user>
>                 <config>
>                         <nickname>ML</nickname>
>                         <top>/</top>
>                         <store>/ML</store>
>                 </config>
>                 <information>
>                         <nachname>Loges</nachname>
>                         <vorname>Marc</vorname>
>                         <anschrift>-</anschrift>
>                         <plz>00000</plz>
>                         <ort>Wuppertal</ort>
>                         <telefon>0202-???</telefon>
>                         <telefax>-</telefax>
>                         <email>ml@kbld.de</email>
>                 </information>
>         </user>
> </users>

--
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc.
1200 Pacific Avenue, Suite 300
Santa Cruz, CA 95060 USA
http://www.lutris.com
http://www.enhydra.org


--__--__--

_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com

End of jdom-interest Digest_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com


From sligade at claravista.com  Wed Sep 20 09:47:12 2000
From: sligade at claravista.com (Ligade, Shailesh)
Date: Fri Aug  6 17:05:01 2004
Subject: [jdom-interest] DTD file and multiple namespaces
Message-ID: <61AFDCD264A7D211A09300105AC8A2838BA6CF@mail.claravista.com>

Hello

Can any one show me how to use xml file which has multiple namespaces and
use of validating parcer with JDOM.

I can't get that to work. I can create the xml file all right but can't
generate a DTD to make parser happy.


Thanks in advance

Shailesh

From vreddy at whn.com  Wed Sep 20 13:20:25 2000
From: vreddy at whn.com (Vamshi Reddy)
Date: Fri Aug  6 17:05:01 2004
Subject: [jdom-interest] RE: no method: Element.setName(String)
In-Reply-To: <213B28F4301DD411A81300508B0CCCDAB5BB95@WHNEXG01.hq.whn.com>
Message-ID: <213B28F4301DD411A81300508B0CCCDA0810E7@WHNEXG01.hq.whn.com>

Travers,

I had the same question. Brett said that it was intensionally removed. I
found an alternate solution to this problem although it can be
memory-intensive if the element/tree is large.

This message was never posted? See below. Hope this helps.

Vamshi Reddy

RE: Class org.jdom.Element

methods: setName(string), setName(string, string)

These methods are in current JavaDoc drop:  jdom-b3_docs(168k). Jason
replied to the mail (sorry for sending it direct) by saying that these
methods were intentionally removed. If a default constructor Element() is
available then how is it possible to set the name after creating and setting
all the required nodes?

If you try to take a child element from another parent element and add it to
a newly created root element, an exception is thrown as this is not allowed.
A way around this is to  clone the required element and add it to the new
root element. If all you wanted to do is to perform an in-line update to the
current document and send it to an output stream.


 Element oldChild =
(Element)document.getRootElement().getChild("Child").clone();
 List oldRootAttributes = document.getRootElement().getAttributes(); //save
all old attribs
 doc = null; //dump the old document or ...

Element newRootElement = new Element("NewRoot");
  newElement.setAttributes(oldRootAttributes); //or individually add:
newElement.setAttribute("name", "value")
	.....more code......

document = new Document(newRootElement, new
DocType(newRootElement.getName(), "external.dtd"));

All this can be avoided by setName(). I modified the source at the time I
needed it but removed it after I received the mail to avoid future errors as
the updates occur.

Please suggest any better ways of getting around this.

Thanks,

vr

-----Original Message-----
From: jdom-interest-admin@jdom.org
[mailto:jdom-interest-admin@jdom.org]On Behalf Of
jdom-interest-request@jdom.org
Sent: Tuesday, September 19, 2000 11:02 PM
To: jdom-interest@jdom.org
Subject: jdom-interest digest, Vol 1 #246 - 13 msgs


Send jdom-interest mailing list submissions to
	jdom-interest@jdom.org

To subscribe or unsubscribe via the World Wide Web, visit
	http://lists.denveronline.net/mailman/listinfo/jdom-interest
or, via email, send a message with subject or body 'help' to
	jdom-interest-request@jdom.org

You can reach the person managing the list at
	jdom-interest-admin@jdom.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of jdom-interest digest..."


Today's Topics:

  1. Re: DTD im XML-File and Element.getContent() (Marcus Breig)
  2. no method: Element.setName(String). Why? (Travers Waker)
  3. Re: Off Topic - XSL (Xalan) question (Aidan Killian)
  4. Problem with DTD (Steven Smith)
  5. static data needs to be thread data for multithreaded application
 s (Nick Reeves)
  6. XMLOutputter - setExpandEmptyElements(true) not functioning
 properly. (kendrick@us.ibm.com)
  7. [BUG] (Wolfgang Werner)
  8. Re: [BUG] (Brett McLaughlin)
  9. Re: XMLOutputter - setExpandEmptyElements(true) not
 functioningproperly. (Brett McLaughlin)
  10. Re: DTD im XML-File and Element.getContent() (Brett McLaughlin)

--__--__--

Message: 1
Date: Tue, 19 Sep 2000 09:01:39 +0200
From: Marcus Breig <mbreig@i2ag.de>
Reply-To: mbreig@i2ag.de
Organization: IQUADRAT AG, Wuppertal
To: Brett McLaughlin <brett.mclaughlin@lutris.com>
CC: JDOM-Liste <jdom-interest@jdom.org>
Subject: Re: [jdom-interest] DTD im XML-File and Element.getContent()
boundary="------------3EBF27EA2DD375AE51700D86"

Dies ist eine mehrteilige Nachricht im MIME-Format.
--------------3EBF27EA2DD375AE51700D86
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Brett,

the XML-File (with DTD) in the attachment...

Marcus

Brett McLaughlin schrieb:

> Marcus Breig wrote:
> > My problem: my sample XML-File contains a DTD for
> > defining my XML-language. In this case the method
> > Element.getContent() always returns an empty string.
>
> Can you post your XML document? I think I know what this is, but I want
> to make sure.
>
> Thanks
> Brett

--------------3EBF27EA2DD375AE51700D86
Content-Type: text/xml; charset=iso-8859-1;
 name="users.xml"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline;
 filename="users.xml"

<?xml version='1.0' encoding="ISO-8859-1" standalone="yes" ?>

<!DOCTYPE users [

	<!ELEMENT users (groups, user+) >

		<!ELEMENT groups (group)+ >
			<!ELEMENT group (members, accessRights, commandRights)+ >
			<!ATTLIST group name CDATA #REQUIRED >
				<!ELEMENT members (member)+ >
					<!ELEMENT member (#PCDATA) >
				<!ELEMENT accessRights (table)+ >
					<!ELEMENT table EMPTY >
					<!ATTLIST table name CDATA #REQUIRED >
					<!ATTLIST table canRead (true|false) "false" >
					<!ATTLIST table canWrite (true|false) "false" >
				<!ELEMENT commandRights (tableCmds)+  >
					<!ELEMENT tableCmds (command)+ >
					<!ATTLIST tableCmds tablename CDATA #REQUIRED >
						<!ELEMENT command EMPTY >
						<!ATTLIST command name CDATA #REQUIRED >
						<!ATTLIST command allowed (true|false) "false" >
		<!ELEMENT user (config, accessRights*, commandRights*, information*) >
			<!ELEMENT config (nickname, top, store) >
				<!ELEMENT nickname (#PCDATA) >
				<!ELEMENT top (#PCDATA) >
				<!ELEMENT store (#PCDATA) >
			<!ELEMENT information (nachname, vorname, anschrift, plz, ort, telefon,
telefax, email) >
				<!ELEMENT nachname (#PCDATA) >
				<!ELEMENT vorname (#PCDATA) >
				<!ELEMENT anschrift (#PCDATA) >
				<!ELEMENT plz (#PCDATA) >
				<!ELEMENT ort (#PCDATA) >
				<!ELEMENT telefon (#PCDATA) >
				<!ELEMENT telefax (#PCDATA) >
				<!ELEMENT email (#PCDATA) >
]>

<!-- hier folgt die Beschreibung der Benutzergruppen, Zugriffsrechte und
Benutzer -->

<users>

	<groups>

		<group name="projektleiter">
			<members>
				<member>MB</member>
				<member>RS</member>
			</members>
			<accessRights>
				<table name="adressen" canRead="true" canWrite="true" />
				<table name="dokumente" canRead="true" canWrite="true" />
				<table name="projekte" canRead="true" canWrite="true" />
			</accessRights>
			<commandRights>
				<tableCmds tablename="adressen">
					<command name="new" allowed="true" />
					<command name="edit" allowed="true" />
					<command name="delete" allowed="true" />
					<command name="copy" allowed="true" />
				</tableCmds>
				<tableCmds tablename="dokumente">
					<command name="new" allowed="true" />
					<command name="edit" allowed="true" />
					<command name="export" allowed="true" />
					<command name="import" allowed="true" />
					<command name="lock" allowed="true" />
					<command name="copy" allowed="true" />
					<command name="release" allowed="true" />
					<command name="delete" allowed="true" />
					<command name="view" allowed="true" />
				</tableCmds>
				<tableCmds tablename="projekte">
					<command name="new" allowed="true" />
					<command name="edit" allowed="true" />
					<command name="delete" allowed="true" />
					<command name="copy" allowed="true" />
				</tableCmds>
			</commandRights>
		</group>
	</groups>


	<user>
		<config>
			<nickname>SM</nickname>
			<top>/</top>
			<store>/ENTWICKLUNG/SOURCE/SM</store>
		</config>
		<information>
			<nachname>Meisner</nachname>
			<vorname>Hans Georg-Stefan Andreas Bernhard</vorname>
			<anschrift>L?nener Str. 31</anschrift>
			<plz>40472</plz>
			<ort>D?sseldorf</ort>
			<telefon>0211-6011976</telefon>
			<telefax>-</telefax>
			<email>sm@i2ag.de</email>
		</information>
	</user>
	<user>
		<config>
			<nickname>ML</nickname>
			<top>/</top>
			<store>/ML</store>
		</config>
		<information>
			<nachname>Loges</nachname>
			<vorname>Marc</vorname>
			<anschrift>-</anschrift>
			<plz>00000</plz>
			<ort>Wuppertal</ort>
			<telefon>0202-???</telefon>
			<telefax>-</telefax>
			<email>ml@kbld.de</email>
		</information>
	</user>
</users>
--------------3EBF27EA2DD375AE51700D86--


--__--__--

Message: 2
From: "Travers Waker" <traversw@innoforge.co.za>
To: <jdom-interest@jdom.org>
Date: Tue, 19 Sep 2000 10:58:54 +0200
charset="iso-8859-1"
Subject: [jdom-interest] no method: Element.setName(String). Why?

Hi all.

I've found a need for the following method of the Element class (but it
doesn't exist):

 Element.setName(String name)

Is there a technical reason why this method can't exist in the current Jdom?

At the moment I'm getting around this limitations as follows:
use Element.getCopy(String name) to create a clone (deep copy) of the
element.  This is pretty wasteful, because I don't need the original element
tree any more and would liek to reuse it with a new root element name
instread of doing expensive deep copies.

In case you're interested in where I'm applying this: It's to represent
request and response message pairs.  In most cases, the XML request message
is exactly the same as the response message except for:
1. The root element is called {something}ResponseMessage instead of
{something}RequestMessage.
2. The addition of a  ResponseCode child element.
3. The addition of a ResponseMessage child element.

2 and 3 are easy to do with Jdom, but changing the name of the root element
is not.

Thanks for any help or info.

Travers



--__--__--

Message: 3
Date: Tue, 19 Sep 2000 10:50:15 +0100
From: Aidan Killian <aidan@concordianet.com>
Organization: Concordia Net, Inc.
To: jdom-interest@jdom.org, VanDoorenD@icfg.com
Subject: [jdom-interest] Re: Off Topic - XSL (Xalan) question

jdom-interest-request@jdom.org wrote:

>
> From: "Van Dooren, Damian" <VanDoorenD@icfg.com>
> To: "JDOM (E-mail)" <jdom-interest@jdom.org>
> Date: Mon, 18 Sep 2000 11:43:32 -0400
> charset="iso-8859-1"
> Subject: [jdom-interest] Off Topic - XSL (Xalan) question
>
> ...
>
> org.apache.xalan.xslt.XSLProcessorException: The reference to entity
> "subaction"  must end with the ';' delimiter.
>
> This is the line it is dying on:
>
> <a
>
href='http://localhost/login/ActionServer?action=loadpage&subaction=html&fil
> eName=client-inquiry.html'>Client Inquiry</a>
>
> I've included the XSL and have commented out the offending line. If
someone
> could point out what I've done wrong I would greatly appreciated it.
>
> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
>                 version="1.0"
> >
>   <xsl:template match="/">
>     <html>
>       <head><title>Main Menu</title></head>
>
>       <body bgcolor="#FFFFFF">
>         <h2>Main Menu</h2>
>         <p>
> <!-- Why doesn't it like this line?
>         <a
>
href='http://localhost/login/ActionServer?action=loadpage&subaction=html&fil
> eName=client-inquiry.html'>Client Inquiry</a>
> -->
>         </p>
>       </body>
>     </html>
>   </xsl:template>
> </xsl:stylesheet>
>
> Hi Damian,

    The parameter separator in the URL is being interpreted as an entity
reference open; an XML parser sees '&subaction' and says where is the
entity reference close (';').

    You need to escape the '&'s using '&amp;'s as follows (line wrapped by
me):

href='http://localhost/login/ActionServer?action=loadpage&amp;
subaction=html&amp;fileName=client-inquiry.html'>

Regards,
    Aidan Killian



--__--__--

Message: 4
From: "Steven Smith" <ssmith@neonsys.com>
To: jdom-interest@jdom.org
Date: Tue, 19 Sep 2000 10:50:59 -0500
Boundary="0__=Qc36xzptzVvMSf0Gfs5kxuBCf33gOVwbUupCcL4uzjFlLveJqQnqLcN1"
Subject: [jdom-interest] Problem with DTD

--0__=Qc36xzptzVvMSf0Gfs5kxuBCf33gOVwbUupCcL4uzjFlLveJqQnqLcN1
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline



(Embedded image moved to file: pic22322.pcx)   Steven Smith @ NEON
09/19/2000 10:50 AM


My apologies for the most basis of questions....

I have a very simple XML document that I'm trying to manipulate with JDOM.
The DOCTYPE is as follows:

     <!DOCTYPE test SYSTEM "test.dtd">

When I attempt to construct a Document via SAXBuilder.build(), I get the
following exception:

     org.jdom.JDOMException: File "test.dtd" not found.: Error on line 0:
File "test.dtd" not found.

I am running my program from the command prompt in Windows 2000 and
test.dtd is in my current directory.  I don't understand why the dtd can't
be located.

Any help would be most appreciated.

Thanks,

Steven

--0__=Qc36xzptzVvMSf0Gfs5kxuBCf33gOVwbUupCcL4uzjFlLveJqQnqLcN1
Content-type: application/octet-stream;
	name="pic22322.pcx"
Content-Disposition: attachment; filename="pic22322.pcx"
Content-transfer-encoding: base64

CgUBCAAAAAAtADMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAABLgABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAADYD8wPxg/DDw/YD8wPxg/DDw/YD8wPxg/DDw/YD8wPxg/DDw/CDw4PDtUP
yw/FD8MPDw8ODw4PDtUPyg/FD8MPDw4PDg8ODw7UD8oPxQ/DDw8PDg8ODw4PDtQPyg/FD8IPDw4P
Dg8ODw7UD8oPxQ/DDw8PDg8ODw4PDsgPxA7OD8cPww/CD8IPDg8ODw7ID8YOzQ/HD8MPwg/DDw4P
DsgPyA7ND8YPww/CD84PyA7ND8YPww/CD84PyA7ND8YPww/CD84PyA7ND8YPww/CD88Pxg7ND8cP
ww/CD9APxA7OD8cPww/CD9gPxA8ODA4MyA/ED8IP2A/DDw4MDgwODMcPxA/CD9gPwg8ODA4MDgwO
DMcPww/CD9gPwg8MDgwODA4MDscPww/CD9gPwg8ODA4MDgwODMcPww/CD9gPwg8MDgwODA4MDscP
ww/CD9gPww8MDgwODA7HD8QPwg/YD8QPDA4MDsgPxA/CD9gPzA/GD8MPD9gPzA/GD8MPD9gPzA/G
D8MPD9gPzA/GD8MPD9gPzA/EDMQPwg/YD8sPxgzDD8IP2A/KD8cMDMMPD9gPyg/HDAzDDw/YD8oP
xwwMww8P2A/KD8cMDMMPD9gPyw/GDMMPwg/YD8wPxAzED8IP2A/MD8YPww8P2A/MD8YPww8P2A/M
D8YPww8P2A/MD8YPww8P2A/MD8YPww8P2A/MD8YPww8P2A/MD8YPww8P2A/MD8MPxATCDw/YD8wP
wg/FBATCD9gPzA8PxQTDBA/YD8wPD8UEwwQP2A/MDw/FBMMED9gPzA8PxQTDBA/YD8wPwg/FBATC
D9gPzA/DD8QEwg8PDAAAAIAAAACAAICAAAAAgIAAgACAgICAgMDAwP8AAAD/AP//AAAA//8A/wD/
/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==

--0__=Qc36xzptzVvMSf0Gfs5kxuBCf33gOVwbUupCcL4uzjFlLveJqQnqLcN1--


--__--__--

Message: 5
From: Nick Reeves <Nick.Reeves@gtl.com>
To: "'jdom-interest@jdom.org'" <jdom-interest@jdom.org>
Date: Tue, 19 Sep 2000 15:40:03 +0100
charset="iso-8859-1"
Subject: [jdom-interest] static data needs to be thread data for
multithreaded application
s

Let me make clear first of all I am not asking for individual JDOM Objects
to be thread safe. I fully agree that the caller should be responsible for
this, following the example of the Java Collections API.

However where the class has hidden static data (such as
Namespace.namespaces)the class must be responsible for making access to this
thread safe otherwise multithreaded applications such as your typical Web or
EJB case, have no choice but to single thread all use of the JDOM packages
:(. This would lead to appalling performance in any realistic use.

At present multihreaded use of Namespace.getNamespace even indirectly (eg by
importing files in different threads) will cause random failures with
ConcurrentModificationException.


--__--__--

Message: 6
From: kendrick@us.ibm.com
To: jdom-interest@jdom.org
Date: Tue, 19 Sep 2000 13:13:44 -0400
Subject: [jdom-interest] XMLOutputter - setExpandEmptyElements(true) not
functioning
properly.



I am seeing my empty elements (content of an empty String) outputted in the
shorthand format (<tagName />) even after I issued
setExpandEmptyElements(true).  I traced the code in XMLOutputter.
printElement() to:

     ...
     if (empty) {
          // Simply close up
          if (!expandEmptyElements) {
               out.write(" />");
          } else {
               out.write("></");
               out.write(element.getQualifiedName());
               out.write(">");
          }
          maybePrintln(out);
     } else if (stringOnly) {
          // Print the tag  with String on same line
          // Example: <tag name="value">content</tag>
          // Also handle "" being added to content
          String elementText = element.getText();
          if ((elementText != null) && (!elementText.equals(""))) {
               out.write(">");
               out.write(escapeElementEntities(element.getText()));
               out.write("</");
               out.write(element.getQualifiedName());
               out.write(">");
          } else {
==========>
== here ==>         out.write(" />");
==========>
          }
          maybePrintln(out);
     } else {
     ...

Apparently the check for expandEmptyElements needs to occur here as well.

Sincerely,
Shannon

IBM e-business Integration Services
3200 Windy Hill Road - Atlanta, GA 30332 - WG06B
Phone: 770-835-7672 T/L 445   FAX: 770-835-6479
Internet: kendrick@us.ibm.com



--__--__--

Message: 7
From: "Wolfgang Werner" <wwerner@picturesafe.de>
To: "Jdom-Interest@Jdom. Org" <jdom-interest@jdom.org>
Date: Tue, 19 Sep 2000 22:15:44 +0200
charset="iso-8859-1"
Subject: [jdom-interest] [BUG]

Hello,

I think I found a very small Bug in Element.java:

If you create an Element without textual content, e.g

	Element e = new Element("test");

and put it into an Document, the function

	e.getText()

on this element fails with a NullPointerException due to the
shortcut in the first lines: Access to content.

A short look at the code reveals that other funtions do a
test for this before atempting to access the content list.

Did I miss something? I tested this on the CVS code from
(i think) two days ago.

Thanks,

	Wolfgang Werner

--__--__--

Message: 8
Date: Tue, 19 Sep 2000 19:27:45 -0500
From: Brett McLaughlin <brett.mclaughlin@lutris.com>
Organization: Lutris Technologies
CC: "Jdom-Interest@Jdom. Org" <jdom-interest@jdom.org>
Subject: Re: [jdom-interest] [BUG]



Wolfgang Werner wrote:
>
> Hello,
>
> I think I found a very small Bug in Element.java:
>
> If you create an Element without textual content, e.g
>
>         Element e = new Element("test");
>
> and put it into an Document, the function
>
>         e.getText()
>
> on this element fails with a NullPointerException due to the
> shortcut in the first lines: Access to content.
>
> A short look at the code reveals that other funtions do a
> test for this before atempting to access the content list.
>
> Did I miss something? I tested this on the CVS code from
> (i think) two days ago.

I fixed this ... give it a try now with the latest from CVS.

-Brett

>
> Thanks,
>
>         Wolfgang Werner
> _______________________________________________
> To control your jdom-interest membership:
>
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com

--
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc.
1200 Pacific Avenue, Suite 300
Santa Cruz, CA 95060 USA
http://www.lutris.com
http://www.enhydra.org

--__--__--

Message: 9
Date: Tue, 19 Sep 2000 19:30:10 -0500
From: Brett McLaughlin <brett.mclaughlin@lutris.com>
Organization: Lutris Technologies
CC: jdom-interest@jdom.org
Subject: Re: [jdom-interest] XMLOutputter - setExpandEmptyElements(true) not
functioningproperly.



kendrick@us.ibm.com wrote:
>
> I am seeing my empty elements (content of an empty String) outputted in
the
> shorthand format (<tagName />) even after I issued
> setExpandEmptyElements(true).  I traced the code in XMLOutputter.
> printElement() to:
>
>      ...
>      if (empty) {
>           // Simply close up
>           if (!expandEmptyElements) {
>                out.write(" />");
>           } else {
>                out.write("></");
>                out.write(element.getQualifiedName());
>                out.write(">");
>           }
>           maybePrintln(out);
>      } else if (stringOnly) {
>           // Print the tag  with String on same line
>           // Example: <tag name="value">content</tag>
>           // Also handle "" being added to content
>           String elementText = element.getText();
>           if ((elementText != null) && (!elementText.equals(""))) {
>                out.write(">");
>                out.write(escapeElementEntities(element.getText()));
>                out.write("</");
>                out.write(element.getQualifiedName());
>                out.write(">");
>           } else {
> ==========>
> == here ==>         out.write(" />");
> ==========>
>           }
>           maybePrintln(out);
>      } else {
>      ...
>
> Apparently the check for expandEmptyElements needs to occur here as well.

Yup. Just fixed it - try it now, and let me know if it works.

Thanks,
Brett

>
> Sincerely,
> Shannon
>
> IBM e-business Integration Services
> 3200 Windy Hill Road - Atlanta, GA 30332 - WG06B
> Phone: 770-835-7672 T/L 445   FAX: 770-835-6479
> Internet: kendrick@us.ibm.com
>
> _______________________________________________
> To control your jdom-interest membership:
>
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com

--
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc.
1200 Pacific Avenue, Suite 300
Santa Cruz, CA 95060 USA
http://www.lutris.com
http://www.enhydra.org

--__--__--

Message: 10
Date: Tue, 19 Sep 2000 19:32:17 -0500
From: Brett McLaughlin <brett.mclaughlin@lutris.com>
Organization: Lutris Technologies
CC: JDOM-Liste <jdom-interest@jdom.org>
Subject: Re: [jdom-interest] DTD im XML-File and Element.getContent()



Marcus Breig wrote:
>
> Hi Brett,
>
> the XML-File (with DTD) in the attachment...

Ahhh, yes. We have some known problems with inline DOCTYPE definitions -
I will work on this soon, and report the fix. Thanks!

-Brett

>
> Marcus
>
> Brett McLaughlin schrieb:
>
> > Marcus Breig wrote:
> > > My problem: my sample XML-File contains a DTD for
> > > defining my XML-language. In this case the method
> > > Element.getContent() always returns an empty string.
> >
> > Can you post your XML document? I think I know what this is, but I want
> > to make sure.
> >
> > Thanks
> > Brett
>
>   ------------------------------------------------------------------------
> <?xml version='1.0' encoding="ISO-8859-1" standalone="yes" ?>
>
> <!DOCTYPE users [
>
>         <!ELEMENT users (groups, user+) >
>
>                 <!ELEMENT groups (group)+ >
>                         <!ELEMENT group (members, accessRights,
commandRights)+ >
>                         <!ATTLIST group name CDATA #REQUIRED >
>                                 <!ELEMENT members (member)+ >
>                                         <!ELEMENT member (#PCDATA) >
>                                 <!ELEMENT accessRights (table)+ >
>                                         <!ELEMENT table EMPTY >
>                                         <!ATTLIST table name CDATA
#REQUIRED >
>                                         <!ATTLIST table canRead
(true|false) "false" >
>                                         <!ATTLIST table canWrite
(true|false) "false" >
>                                 <!ELEMENT commandRights (tableCmds)+  >
>                                         <!ELEMENT tableCmds (command)+ >
>                                         <!ATTLIST tableCmds tablename
CDATA #REQUIRED >
>                                                 <!ELEMENT command EMPTY >
>                                                 <!ATTLIST command name
CDATA #REQUIRED >
>                                                 <!ATTLIST command allowed
(true|false) "false" >
>                 <!ELEMENT user (config, accessRights*, commandRights*,
information*) >
>                         <!ELEMENT config (nickname, top, store) >
>                                 <!ELEMENT nickname (#PCDATA) >
>                                 <!ELEMENT top (#PCDATA) >
>                                 <!ELEMENT store (#PCDATA) >
>                         <!ELEMENT information (nachname, vorname,
anschrift, plz, ort, telefon, telefax, email) >
>                                 <!ELEMENT nachname (#PCDATA) >
>                                 <!ELEMENT vorname (#PCDATA) >
>                                 <!ELEMENT anschrift (#PCDATA) >
>                                 <!ELEMENT plz (#PCDATA) >
>                                 <!ELEMENT ort (#PCDATA) >
>                                 <!ELEMENT telefon (#PCDATA) >
>                                 <!ELEMENT telefax (#PCDATA) >
>                                 <!ELEMENT email (#PCDATA) >
> ]>
>
> <!-- hier folgt die Beschreibung der Benutzergruppen, Zugriffsrechte und
Benutzer -->
>
> <users>
>
>         <groups>
>
>                 <group name="projektleiter">
>                         <members>
>                                 <member>MB</member>
>                                 <member>RS</member>
>                         </members>
>                         <accessRights>
>                                 <table name="adressen" canRead="true"
canWrite="true" />
>                                 <table name="dokumente" canRead="true"
canWrite="true" />
>                                 <table name="projekte" canRead="true"
canWrite="true" />
>                         </accessRights>
>                         <commandRights>
>                                 <tableCmds tablename="adressen">
>                                         <command name="new" allowed="true"
/>
>                                         <command name="edit"
allowed="true" />
>                                         <command name="delete"
allowed="true" />
>                                         <command name="copy"
allowed="true" />
>                                 </tableCmds>
>                                 <tableCmds tablename="dokumente">
>                                         <command name="new" allowed="true"
/>
>                                         <command name="edit"
allowed="true" />
>                                         <command name="export"
allowed="true" />
>                                         <command name="import"
allowed="true" />
>                                         <command name="lock"
allowed="true" />
>                                         <command name="copy"
allowed="true" />
>                                         <command name="release"
allowed="true" />
>                                         <command name="delete"
allowed="true" />
>                                         <command name="view"
allowed="true" />
>                                 </tableCmds>
>                                 <tableCmds tablename="projekte">
>                                         <command name="new" allowed="true"
/>
>                                         <command name="edit"
allowed="true" />
>                                         <command name="delete"
allowed="true" />
>                                         <command name="copy"
allowed="true" />
>                                 </tableCmds>
>                         </commandRights>
>                 </group>
>         </groups>
>
>         <user>
>                 <config>
>                         <nickname>SM</nickname>
>                         <top>/</top>
>                         <store>/ENTWICKLUNG/SOURCE/SM</store>
>                 </config>
>                 <information>
>                         <nachname>Meisner</nachname>
>                         <vorname>Hans Georg-Stefan Andreas
Bernhard</vorname>
>                         <anschrift>L?nener Str. 31</anschrift>
>                         <plz>40472</plz>
>                         <ort>D?sseldorf</ort>
>                         <telefon>0211-6011976</telefon>
>                         <telefax>-</telefax>
>                         <email>sm@i2ag.de</email>
>                 </information>
>         </user>
>         <user>
>                 <config>
>                         <nickname>ML</nickname>
>                         <top>/</top>
>                         <store>/ML</store>
>                 </config>
>                 <information>
>                         <nachname>Loges</nachname>
>                         <vorname>Marc</vorname>
>                         <anschrift>-</anschrift>
>                         <plz>00000</plz>
>                         <ort>Wuppertal</ort>
>                         <telefon>0202-???</telefon>
>                         <telefax>-</telefax>
>                         <email>ml@kbld.de</email>
>                 </information>
>         </user>
> </users>

--
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc.
1200 Pacific Avenue, Suite 300
Santa Cruz, CA 95060 USA
http://www.lutris.com
http://www.enhydra.org


--__--__--

_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com

End of jdom-interest Digest_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com


From Nick.Reeves at gtl.com  Thu Sep 21 02:38:03 2000
From: Nick.Reeves at gtl.com (Nick Reeves)
Date: Fri Aug  6 17:05:01 2004
Subject: [jdom-interest] static data needs to be thread safe for multithreaded application
 s
Message-ID: <AF7105DDF744D311A7DF005004B07090C6DF4A@exchange1.gtl.com>

When I originally sent this message there was I typo in the subject line
which may have confused people. There have been no replies to this which
expressed an opinion as to whether this was a problem. Do I infer from this
that people don't think this is a problem, if so why.

To be more explicit about a particular example of the problem:

In jdom-b4 The Namespace class has a static field namespaces which is a
HashMap holding
all the Namespaces made so far. Namespace.getNamespace reads and writes this
HashMap. However HashMaps are not thread safe, and multiple use from
different threads will lead to unpredictable results including corrupting
the HashMap, or creating two equivalent Namespaces which won't be ==. This
will only happen in rare race conditions when two threads try and create a
Namespace at the same time.

Since Namespace.getNamespace can get called indirectly by so many other
entry points about the only way to avoid this is to single thread all use of
the JDOM packages which is clearly extremely restrictive.


> Nick Reeves wrote:
> > 
> > Let me make clear first of all I am not asking for 
> individual JDOM Objects
> > to be thread safe. I fully agree that the caller should be 
> responsible for
> > this, following the example of the Java Collections API.
> > 
> > However where the class has hidden static data (such as
> > Namespace.namespaces)the class must be responsible for 
> making access to this
> > thread safe otherwise multithreaded applications such as 
> your typical Web or
> > EJB case, have no choice but to single thread all use of 
> the JDOM packages
> > :(. This would lead to appalling performance in any realistic use.
> > 
> > At present multihreaded use of Namespace.getNamespace even 
> indirectly (eg by
> > importing files in different threads) will cause random 
> failures with
> > ConcurrentModificationException.
> 

From kmorehead at idiominc.com  Thu Sep 21 04:49:27 2000
From: kmorehead at idiominc.com (Kem Morehead)
Date: Fri Aug  6 17:05:01 2004
Subject: [jdom-interest] Element.getText() bug
Message-ID: <43EA80F14C3ED411841D00508BAE017D1D0730@wal-zulu.idiomtech.com>

I assume if I add the line:

if (content == null) return null;

everything will work.

Is that the only change?

Thanks.

kem

-------------------------------------------------
Kem Morehead, software engineer
Idiom, Inc. [www.idiominc.com]
781.464.6113
kmorehead@idiominc.com


From wendy.liew at home.com  Wed Sep 20 18:53:15 2000
From: wendy.liew at home.com (Wendy Liew)
Date: Fri Aug  6 17:05:01 2004
Subject: [jdom-interest] Support for JDK11
Message-ID: <NEBBKNALJKLKEIHLDBFMGEBOCBAA.wendy.liew@home.com>

HI, I downloaded JDOM (the latest one as of yesterday) and import
them into vage.  Since we are using vage 3 for jdk11, jdom
doesn't compile as it uses new APIs introduced for jdk12.  Is
there a plan to tweak the code to use jdk11 only, perhaps with 
the com.sun.java.util.collections.* classes from Sun...

thanks,
wendy

From brett.mclaughlin at lutris.com  Thu Sep 21 07:54:33 2000
From: brett.mclaughlin at lutris.com (Brett McLaughlin)
Date: Fri Aug  6 17:05:01 2004
Subject: [jdom-interest] Support for JDK11
References: <NEBBKNALJKLKEIHLDBFMGEBOCBAA.wendy.liew@home.com>
Message-ID: <39CA2129.4AD9A5D2@lutris.com>


Wendy Liew wrote:
> 
> HI, I downloaded JDOM (the latest one as of yesterday) and import
> them into vage.  Since we are using vage 3 for jdk11, jdom
> doesn't compile as it uses new APIs introduced for jdk12.  Is
> there a plan to tweak the code to use jdk11 only, perhaps with
> the com.sun.java.util.collections.* classes from Sun...

Run build11.bat and it will convert the classes to Java 1.1

-Brett

> 
> thanks,
> wendy
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org

From jools at jools.org  Thu Sep 21 08:11:24 2000
From: jools at jools.org (Jools Enticknap)
Date: Fri Aug  6 17:05:01 2004
Subject: [jdom-interest] Support for JDK11
References: <NEBBKNALJKLKEIHLDBFMGEBOCBAA.wendy.liew@home.com> <39CA2129.4AD9A5D2@lutris.com>
Message-ID: <39CA251C.DFF0C2A2@jools.org>

Brett McLaughlin wrote:
> 
> Wendy Liew wrote:
> >
> > HI, I downloaded JDOM (the latest one as of yesterday) and import
> > them into vage.  Since we are using vage 3 for jdk11, jdom
> > doesn't compile as it uses new APIs introduced for jdk12.  Is
> > there a plan to tweak the code to use jdk11 only, perhaps with
> > the com.sun.java.util.collections.* classes from Sun...
> 
> Run build11.bat and it will convert the classes to Java 1.1

And don't forget to add the collections.jar file to your applications 
class path.

You'll find it in the lib directory of the JDOM distribution.

--Jools


> 
> -Brett
> 
> >
> > thanks,
> > wendy
> > _______________________________________________
> > To control your jdom-interest membership:
> > http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
> 
> --
> Brett McLaughlin, Enhydra Strategist
> Lutris Technologies, Inc.
> 1200 Pacific Avenue, Suite 300
> Santa Cruz, CA 95060 USA
> http://www.lutris.com
> http://www.enhydra.org
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com

From Brad.Morgan at e-pubcorp.com  Thu Sep 21 08:36:32 2000
From: Brad.Morgan at e-pubcorp.com (Brad Morgan)
Date: Fri Aug  6 17:05:01 2004
Subject: [jdom-interest] Support for JDK11
In-Reply-To: <NEBBKNALJKLKEIHLDBFMGEBOCBAA.wendy.liew@home.com>
Message-ID: <NDBBLFGNKKGCBIJEAIJBIEADCHAA.Brad.Morgan@e-pubcorp.com>

The JDOM build procedures (using ANT) do build a version that works with JDK
1.1 by doing exactly as you suggest, using the
com.sun.java.util.collections.* classes.

It sounds to me like you just imported the sources into another build
environment and lost
the benefit of the JDOM build procedures which automatically create JDK 1.1
compatible sources as part of the build process.

Regards,

Brad Morgan
e-Publishing Corp.

Email: Brad.Morgan@e-pubcorp.com
Phone: (719)593-7377 x35
Fax: (719)593-2996

e-Publishing Corp. is a BroadVision company
NOTICE: This message is intended only for the use of the Addressee and may
contain information that is PRIVILEGED and CONFIDENTIAL. If you are not the
intended recipient, dissemination of this communication is prohibited. If
you have received this communication in error, please erase all copies of
the message and its attachments and notify us immediately.



-----Original Message-----
From: jdom-interest-admin@jdom.org
[mailto:jdom-interest-admin@jdom.org]On Behalf Of Wendy Liew
Sent: Wednesday, September 20, 2000 7:53 PM
To: JDOM - XML
Subject: [jdom-interest] Support for JDK11


HI, I downloaded JDOM (the latest one as of yesterday) and import
them into vage.  Since we are using vage 3 for jdk11, jdom
doesn't compile as it uses new APIs introduced for jdk12.  Is
there a plan to tweak the code to use jdk11 only, perhaps with
the com.sun.java.util.collections.* classes from Sun...

thanks,
wendy
_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com


From pvg at c-c-s.com  Thu Sep 21 08:31:46 2000
From: pvg at c-c-s.com (Peter V. Gadjokov)
Date: Fri Aug  6 17:05:01 2004
Subject: [jdom-interest] Support for JDK11
Message-ID: <704ECFDA88B3D311B5F000A0C959E5B601FC0F@adobo.c2labs.com>

JDOM supports Java 1.1, the sources get munged to use the 1.1 collections
classes at build time. The easiest thing is to build (use the build11
script) with ant on the command line with the JDK 1.1 tools and the
collection classes around. Then you can use the generated JAR file.
Alternatively, if you really want to import compilable sources into VA, you
should be able to use the sources sitting around in the build/src directory
after a build.

-pvg

> -----Original Message-----
> From: Wendy Liew [mailto:wendy.liew@home.com]
> Sent: Wednesday, September 20, 2000 6:53 PM
> To: JDOM - XML
> Subject: [jdom-interest] Support for JDK11
> 
> 
> HI, I downloaded JDOM (the latest one as of yesterday) and import
> them into vage.  Since we are using vage 3 for jdk11, jdom
> doesn't compile as it uses new APIs introduced for jdk12.  Is
> there a plan to tweak the code to use jdk11 only, perhaps with 
> the com.sun.java.util.collections.* classes from Sun...
> 
> thanks,
> wendy
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/yo
uraddr@yourhost.com
> 

From jpeck at stshotelnet.com  Thu Sep 21 08:26:17 2000
From: jpeck at stshotelnet.com (Jason Peck)
Date: Fri Aug  6 17:05:01 2004
Subject: [jdom-interest] RE: Element.getText()
Message-ID: <000201c023e0$49edc6a0$690c010a@stshotelnet.com>

Brett,

I retrieved the last version of the source from CVS today 9/21/00 and can
see that modifications were made to Element.java.  However, I still get a
NullPointerException when I try to access the getText() method of the empty
element if I dont first call a XMLOutputter.output() with the document.

Thanks,
Jason


From guru at edamame.stinky.com  Thu Sep 21 09:18:52 2000
From: guru at edamame.stinky.com (Alex Chaffee)
Date: Fri Aug  6 17:05:01 2004
Subject: [jdom-interest] BeanMapper
In-Reply-To: <20000920100815.F5659@edamame.stinky.com>; from guru@edamame.stinky.com on Wed, Sep 20, 2000 at 10:08:15AM -0700
References: <20000920100815.F5659@edamame.stinky.com>
Message-ID: <20000921091852.B31367@edamame.stinky.com>

On Wed, Sep 20, 2000 at 10:08:15AM -0700, Alex Chaffee wrote:
> Because there weren't enough XML Data Binding technologies already, I
> just wrote one using JDOM.
> 

Brett replied:
> Not reading DeveloperWorks at IBM, are you ;-) There's a complete
> framework, covered in 4 articles, there. It's based on JDOM and written
> by yours truly ;-) 

I just did -- looks nice.  

I just skimmed it, but apparently, it doesn't use reflection, and it
seems to generate custom bean classes.  This means that its unsuitable
for the case where you already have a bean, that works just fine
thanks, and may have custom methods, and you want to either serialize
it as XML, or load an XML data structure into it.

Mine does.  I'm not saying it's the ultimate framework, just that it's
really easy to use.  


-- 
Alex Chaffee                       mailto:alex@jguru.com
jGuru - Java News and FAQs         http://www.jguru.com/alex/
Creator of Gamelan                 http://www.gamelan.com/
Founder of Purple Technology       http://www.purpletech.com/
Curator of Stinky Art Collective   http://www.stinky.com/

From guru at edamame.stinky.com  Thu Sep 21 09:33:47 2000
From: guru at edamame.stinky.com (Alex Chaffee)
Date: Fri Aug  6 17:05:01 2004
Subject: [jdom-interest] BeanMapper
In-Reply-To: <20000920100815.F5659@edamame.stinky.com>; from guru@edamame.stinky.com on Wed, Sep 20, 2000 at 10:08:15AM -0700
References: <20000920100815.F5659@edamame.stinky.com>
Message-ID: <20000921093347.D31367@edamame.stinky.com>

On Wed, Sep 20, 2000 at 10:08:15AM -0700, Alex Chaffee wrote:
> Because there weren't enough XML Data Binding technologies already, I
> just wrote one using JDOM.

Also, my BeanMapper has support for arrays as property types, and you
can map properties to either elements or attributes.  Attributes must
map to simple properties (ints or strings or other primitives) but
elements can either be mapped to simple properties, or complex ones
(that are themselves beans).  Brett's marshaller/unmarshaller requires
elements to be complex and attributes to be primitive.

However, his SchemaMapper kicks major ass.
http://www-4.ibm.com/software/developer/library/data-binding3/SchemaMapper.html

> I seem to have misplaced my CVS password.  Jools, can you please
> contact me about checking this in?  In the meantime, anyone who wants
> to play, please email me privately.


-- 
Alex Chaffee                       mailto:alex@jguru.com
jGuru - Java News and FAQs         http://www.jguru.com/alex/
Creator of Gamelan                 http://www.gamelan.com/
Founder of Purple Technology       http://www.purpletech.com/
Curator of Stinky Art Collective   http://www.stinky.com/

From brett.mclaughlin at lutris.com  Thu Sep 21 10:23:47 2000
From: brett.mclaughlin at lutris.com (Brett McLaughlin)
Date: Fri Aug  6 17:05:01 2004
Subject: [jdom-interest] getText and NullPointerException
Message-ID: <39CA4423.E0812E1C@lutris.com>

I've just made some more changes to getText in Element.java. Try these
and let me know if it resolves the NullPointerException.

In the future, reporting an Exception without the stack trace or echo of
your screen is really difficult to track. Can you be sure that send the
trace when running on future errors?

Thanks,
Brett
-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org

From aspicool at yahoo.com  Thu Sep 21 11:05:57 2000
From: aspicool at yahoo.com (Aspi Siganporia)
Date: Fri Aug  6 17:05:01 2004
Subject: [jdom-interest] Incrementally output XML to a file
In-Reply-To: <200009202202.QAA03138@dorothy.denveronline.net>
Message-ID: <OJEDJHHEDIEFGPCCMNIFKEINCBAA.aspicool@yahoo.com>

I want to stream periodic stats to a file. The stats are in XML format.

Is there any API in JDOM where we can output elements on the stream instead of a complete JDOM tree.

Even if I try to fake it with the current API to treat the Element as a doc, the XML header tags are output every time.

Any thoughts?

Thanks
Aspi

From wendy.liew at home.com  Wed Sep 20 23:33:13 2000
From: wendy.liew at home.com (Wendy Liew)
Date: Fri Aug  6 17:05:01 2004
Subject: [jdom-interest] problem building jdom for JDK11
In-Reply-To: <NDBBLFGNKKGCBIJEAIJBIEADCHAA.Brad.Morgan@e-pubcorp.com>
Message-ID: <NEBBKNALJKLKEIHLDBFMAECFCBAA.wendy.liew@home.com>

I downloaded the build11.bat as suggested from jdom site.
I am using jdk118_005 from sun.

when i run it, the following error occurs - Unable to initialize threads:
cannot
find class java/lang/Thread.  Is the build expected some other version of
jdk11....which one.  I have includes the collections.jar in the classpath.

For some reason, the classpath printed out by the build script
includes the file tools.jar under my java_home\lib.  BUT
that jar doesn't come with the install of jdk118_005 from sun, i.e.
it does not exist under d:\apps\jdk118\lib.

thanks,
wendy

=======print out of my class path before the error printout ============
Java and XML Build System
-------------------
Building with classpath
d:\apps\jdk118\lib\tools.jar;.\lib\xerces.jar;.\lib\ant.jar;d:\apps\jdk118\c
lasses.zip;d:\Java\1.1collections\lib\collections.jar
Starting Ant...

-----Original Message-----
From: Brad Morgan [mailto:Brad.Morgan@e-pubcorp.com]
Sent: Thursday, September 21, 2000 11:37 AM
To: Wendy Liew; JDOM - XML
Subject: RE: [jdom-interest] Support for JDK11


The JDOM build procedures (using ANT) do build a version that works with JDK
1.1 by doing exactly as you suggest, using the
com.sun.java.util.collections.* classes.

It sounds to me like you just imported the sources into another build
environment and lost
the benefit of the JDOM build procedures which automatically create JDK 1.1
compatible sources as part of the build process.

Regards,

Brad Morgan
e-Publishing Corp.

Email: Brad.Morgan@e-pubcorp.com
Phone: (719)593-7377 x35
Fax: (719)593-2996

e-Publishing Corp. is a BroadVision company
NOTICE: This message is intended only for the use of the Addressee and may
contain information that is PRIVILEGED and CONFIDENTIAL. If you are not the
intended recipient, dissemination of this communication is prohibited. If
you have received this communication in error, please erase all copies of
the message and its attachments and notify us immediately.



-----Original Message-----
From: jdom-interest-admin@jdom.org
[mailto:jdom-interest-admin@jdom.org]On Behalf Of Wendy Liew
Sent: Wednesday, September 20, 2000 7:53 PM
To: JDOM - XML
Subject: [jdom-interest] Support for JDK11


HI, I downloaded JDOM (the latest one as of yesterday) and import
them into vage.  Since we are using vage 3 for jdk11, jdom
doesn't compile as it uses new APIs introduced for jdk12.  Is
there a plan to tweak the code to use jdk11 only, perhaps with
the com.sun.java.util.collections.* classes from Sun...

thanks,
wendy
_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com


From guru at edamame.stinky.com  Thu Sep 21 16:34:24 2000
From: guru at edamame.stinky.com (Alex Chaffee)
Date: Fri Aug  6 17:05:01 2004
Subject: [jdom-interest] Incrementally output XML to a file
In-Reply-To: <OJEDJHHEDIEFGPCCMNIFKEINCBAA.aspicool@yahoo.com>; from aspicool@yahoo.com on Thu, Sep 21, 2000 at 11:05:57AM -0700
References: <200009202202.QAA03138@dorothy.denveronline.net> <OJEDJHHEDIEFGPCCMNIFKEINCBAA.aspicool@yahoo.com>
Message-ID: <20000921163424.T32519@edamame.stinky.com>

Yes, I added this to XMLOutputter, but the patch seemed not to be
applied.  Since XMLOutputter has changed since then I'd have to do a
little work to get it back in.

 - A

On Thu, Sep 21, 2000 at 11:05:57AM -0700, Aspi Siganporia wrote:
> I want to stream periodic stats to a file. The stats are in XML format.
> 
> Is there any API in JDOM where we can output elements on the stream instead of a complete JDOM tree.
> 
> Even if I try to fake it with the current API to treat the Element as a doc, the XML header tags are output every time.
> 
> Any thoughts?
> 
> Thanks
> Aspi
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com

-- 
Alex Chaffee                       mailto:alex@jguru.com
jGuru - Java News and FAQs         http://www.jguru.com/alex/
Creator of Gamelan                 http://www.gamelan.com/
Founder of Purple Technology       http://www.purpletech.com/
Curator of Stinky Art Collective   http://www.stinky.com/

From guru at edamame.stinky.com  Thu Sep 21 18:21:31 2000
From: guru at edamame.stinky.com (Alex Chaffee)
Date: Fri Aug  6 17:05:01 2004
Subject: [jdom-interest] Re: Interfaces? (was: W3 DOM support)
In-Reply-To: <398EBA5A.2794C0EE@mitre.org>; from dsmiley@mitre.org on Mon, Aug 07, 2000 at 09:32:10AM -0400
References: <200008060600.AAA16045@dorothy.denveronline.net> <398EBA5A.2794C0EE@mitre.org>
Message-ID: <20000921182131.D32519@edamame.stinky.com>

Scanning old threads, specifically this one on whether Element et al
should be interfaces:

On Mon, Aug 07, 2000 at 09:32:10AM -0400, David W. Smiley wrote:
> > > And I'm not a big fan of subclassing.  I'd rather delegate.  To my mind,
> > > subclassing is a fragile, often requiring intimate knowledge of the
> > > source code and leaving oneself vulnerable to future revisions of the
> > > base classes.
> > 
> > Hear, hear!  Inheritance is OOP for the weak!  Delegation rules.
> 
>   Excuse me?  This statement suggests inheritance has no purpose.

Inheritance is syntactic sugar (like all OOP actually).  Delegation is
strictly more powerful than inheritance, since all inheritance buys
you is that you don't have to write

 int foo(int bar) {
   return parent.foo(bar);
 }

for all methods you neglect to implement yourself.  Plus, inheritance
has baggage like the abovementioned, and like forcing you to use a
single (inherited) implementation instead of allowing swapping
different implementations in and out.

Note that inheritance is not the same thing as polymorphism, which
rocks.  Inheritance = polymorphism + code sharing


-- 
Alex Chaffee                       mailto:alex@jguru.com
jGuru - Java News and FAQs         http://www.jguru.com/alex/
Creator of Gamelan                 http://www.gamelan.com/
Founder of Purple Technology       http://www.purpletech.com/
Curator of Stinky Art Collective   http://www.stinky.com/

From jhunter at acm.org  Thu Sep 21 19:57:20 2000
From: jhunter at acm.org (Jason Hunter)
Date: Fri Aug  6 17:05:01 2004
Subject: [jdom-interest] problem building jdom for JDK11
References: <NEBBKNALJKLKEIHLDBFMAECFCBAA.wendy.liew@home.com>
Message-ID: <39CACA90.69FA5665@acm.org>

d:\apps\jdk118\lib\tools.jar;.\lib\xerces.jar;.\lib\ant.jar;d:\apps\jdk118\c
> lasses.zip;d:\Java\1.1collections\lib\collections.jar
> Starting Ant...

That classpath doesn't make sense since the build scripts would place
classes.zip *after* collections.jar.  Are you using the latest version? 
Have you modified the scripts?

-jh-

From jhunter at acm.org  Thu Sep 21 13:52:19 2000
From: jhunter at acm.org (Jason Hunter)
Date: Fri Aug  6 17:05:01 2004
Subject: [jdom-interest] static data needs to be thread data for 
 multithreaded applications
References: <AF7105DDF744D311A7DF005004B07090C6DF49@exchange1.gtl.com>
Message-ID: <39CA7503.3672CD2C@acm.org>

> However where the class has hidden static data (such as
> Namespace.namespaces)the class must be responsible for making 
> access to this thread safe otherwise multithreaded applications 
> such as your typical Web or EJB case, have no choice but to single 
> thread all use of the JDOM packages
> :(. This would lead to appalling performance in any realistic use.
> 
> At present multihreaded use of Namespace.getNamespace even 
> indirectly (eg by
> importing files in different threads) will cause random failures with
> ConcurrentModificationException.

I agree.  You should be able to have different threads in the same JVM
using JDOM to create different documents without having collisions
between them.  Each document needs external sync, but you shouldn't need
to get a global lock before reading a new document.  In other words, I
agree we should sync access to static variables but leaving instance
variables unsync'd.  Any disagreement?

Nick, do you want to submit a patch to Namespace that makes access to
the statics sync'd?

-jh-



From jhunter at acm.org  Thu Sep 21 14:20:40 2000
From: jhunter at acm.org (Jason Hunter)
Date: Fri Aug  6 17:05:01 2004
Subject: [jdom-interest] A plea for the orphans
References: <20000916122709.A21612@talsever.com>
	 <39C3E267.3E9F9D00@collab.net> <p04330100b5ea620edb05@[168.100.203.234]>
Message-ID: <39CA7BA8.5883A80C@acm.org>

Elliotte Rusty Harold wrote:
> 
> At 2:13 PM -0700 9/16/00, Jason Hunter wrote:
> 
> >A problem with this is that our String representation of text can't have
> >a getParent() and that's a bit unfortunate but not (imho) unfortunate
> >enough to switch to having a Text class.
> >
> 
> How about if I tossed in that it would eliminate the need for a CDATA
> class since a Text class could easily have an isCDATA property with
> appropriate getter and setter methods? Then we'd be adding one class
> and removing one. Is that fortunate enough to switch you?

I'm not worried about class count but rather intellectual overhead. 
When I first yearned for something like JDOM one core reason was I
wanted those darn strings to be represented as Strings.  

I don't very much like the idea that getMixedContent() would return a
Text instance while getText() returns a String.  That's confusing I
think.  And to not have getText() return a String diminishes the APIs
usability.

-jh-



From engp9818 at nus.edu.sg  Fri Sep 22 00:26:32 2000
From: engp9818 at nus.edu.sg (Abhinav Tyagi)
Date: Fri Aug  6 17:05:01 2004
Subject: [jdom-interest] Error while executing sample
Message-ID: <30A14FB41CC5D311854D00508B5EEF0206D7A0B9@exs23.ex.nus.edu.sg>

I am using JDOM  and have tried the sample code named WarReader.java with
web.xml.
I downloaded the jdom-b3.zip file and extracted it and placed the files
jdom-b3.jar and xerces.jar in my c:\jdk1.3\jre\lib\ext folder.

I am able to compile the java file but following output is coming at the
time of execution.

"Exception in thread "main" java.lang.NoClassDefFoundError:
org/jdom/input/AbstractBuilder"

Help shall be greatly appreciated
Thanks in advance

Abhinav







From jozart at csi.com  Fri Sep 22 04:09:19 2000
From: jozart at csi.com (Joseph Bowbeer)
Date: Fri Aug  6 17:05:01 2004
Subject: [jdom-interest] Re: Interfaces?
References: <200009220602.AAA20332@dorothy.denveronline.net>
Message-ID: <007e01c02485$9512ee30$258a7cce@REPLICANT>

To recap, Jason says interfaces are "been there tried that" and Brett
says there are other ways to achieve the same results.

If someone wants to work out the details of interfaces (again), I'd be
interested in seeing how much pain they introduce.  Also, I'm interested
in knowing what other ways Brett has in mind.

In the near term, though, I was wondering whether the "Visitor Pattern"
might be used to support extensions, as follows.

Given a Visitable interface defined by JDOM:

    interface Visitable {
        void accept(Visitor visitor);
    }

Each concrete object in a document would implement Visitable, for
example:

    class Element implements Visitable {
        // ...
        public void accept(Visitor visitor) {
            visitor.visitElement(this);
        }
    }

JDOM would also define an abstract base class for visitors:

    abstract class Visitor {
        public void visitDocument(Document document);
        public void visitElement(Element element);
        public void visitAttribute(Attribute attribute);
        // ...
    }

(Visitor can be thought of as "subject-oriented" rather than
object-oriented, I believe.)

Would it be beneficial to add Visitor/Visitable to JDOM?


----- Original Message -----
Date: Thu, 21 Sep 2000 18:21:31 -0700
From: Alex Chaffee <guru@edamame.stinky.com>
Cc: jdom-interest@jdom.org
Subject: Re: Interfaces? (was: W3 DOM support)
Reply-To: alex@jguru.com

Scanning old threads, specifically this one on whether Element et al
should be interfaces:

> And I'm not a big fan of subclassing.  I'd rather delegate.  To my
> mind, subclassing is fragile, often requiring intimate knowledge of
> the source code and leaving oneself vulnerable to future revisions
> of the base classes.
>

Inheritance is syntactic sugar (like all OOP actually).  Delegation is
strictly more powerful than inheritance, since all inheritance buys
you is that you don't have to write

 int foo(int bar) {
   return parent.foo(bar);
 }

for all methods you neglect to implement yourself.  Plus, inheritance
has baggage like the abovementioned, and like forcing you to use a
single (inherited) implementation instead of allowing swapping
different implementations in and out.

Note that inheritance is not the same thing as polymorphism, which
rocks.  Inheritance = polymorphism + code sharing

--
Alex Chaffee                       mailto:alex@jguru.com




From jhunter at acm.org  Fri Sep 22 04:09:04 2000
From: jhunter at acm.org (Jason Hunter)
Date: Fri Aug  6 17:05:01 2004
Subject: [jdom-interest] Error while executing sample
References: <30A14FB41CC5D311854D00508B5EEF0206D7A0B9@exs23.ex.nus.edu.sg>
Message-ID: <39CB3DD0.FCA74177@acm.org>

> I downloaded the jdom-b3.zip file 

b3 came out in April.  You might want to look at getting something a
little more recent.  Like the daily snapshot.

-jh-

From jhunter at acm.org  Fri Sep 22 05:03:34 2000
From: jhunter at acm.org (Jason Hunter)
Date: Fri Aug  6 17:05:01 2004
Subject: [jdom-interest] Re: Interfaces?
References: <200009220602.AAA20332@dorothy.denveronline.net> <007e01c02485$9512ee30$258a7cce@REPLICANT>
Message-ID: <39CB4A96.C0FB8246@acm.org>

>     class Element implements Visitable {
>         // ...
>         public void accept(Visitor visitor) {
>             visitor.visitElement(this);
>         }
>     }
> ...
> 
> Would it be beneficial to add Visitor/Visitable to JDOM?

Well, as is our mantra, things are only added to the API when there's a
compelling use case and when the method of satisfying the use case is
unacceptible using the current API.  So to repeat your question in
different words, what's the compelling use case?

-jh-

From Nick.Reeves at gtl.com  Fri Sep 22 05:40:29 2000
From: Nick.Reeves at gtl.com (Nick Reeves)
Date: Fri Aug  6 17:05:01 2004
Subject: [jdom-interest] static data needs to be thread data for  mult
	ithreaded applications
Message-ID: <AF7105DDF744D311A7DF005004B07090C6DF4C@exchange1.gtl.com>

> Nick, do you want to submit a patch to Namespace that makes access to
> the statics sync'd?
> 

What's the procedure for this I can't find anything on the website.

I can't use CVS by the way as I'm behind a firewall.

The actual patch is trivial it's just a matter of add a synchronized block
in getNamespace
as marked with ++ below, and some suitable comments on synch policy.


    public static Namespace getNamespace(String prefix, String uri) {
        // Ensure proper naming
        String reason;
        if ((reason = Verifier.checkNamespacePrefix(prefix)) != null) {
            throw new IllegalNameException(prefix, "Namespace prefix",
reason);
        }
        if ((reason = Verifier.checkNamespaceURI(uri)) != null) {
            throw new IllegalNameException(uri, "Namespace URI", reason);
        }

        // Housekeeping
        if ((prefix == null) || (prefix.trim().equals(""))) {
            prefix = "";
        }
        if ((uri == null) || (uri.trim().equals(""))) {
            uri = "";
        }

        // Unless the "empty" Namespace (no prefix and no URI), require a
URI
        if ((!prefix.equals("")) && (uri.equals(""))) {
            throw new IllegalNameException("", "namespace",
                                           "Namespace URIs must be non-null
and non-empty Strings.");
        }

++	  synchronized (namespaces) {

        // Return existing namespace if found
        if (namespaces.containsKey(uri)) {
            return (Namespace)namespaces.get(uri);
        }

        // Ensure prefix uniqueness in non-default namespaces
        if (!prefix.equals("")) {
            int i = 0;
            String newPrefix = prefix;

            while (mappings.containsKey(newPrefix)) {
                newPrefix = newPrefix + i++;
            }
            prefix = newPrefix;

            // We really don't care to store all the default namespaces, so
            //   storing mappings here is OK
            mappings.put(prefix, uri);
        }

        // Finally, store and return
        Namespace ns = new Namespace(prefix, uri);
        namespaces.put(uri, ns);
        return ns;

++      }
    }

From jhunter at acm.org  Fri Sep 22 08:16:37 2000
From: jhunter at acm.org (Jason Hunter)
Date: Fri Aug  6 17:05:01 2004
Subject: [jdom-interest] static data needs to be thread data for  
 multithreaded applications
References: <AF7105DDF744D311A7DF005004B07090C6DF4C@exchange1.gtl.com>
Message-ID: <39CB77D5.E221778C@acm.org>

> What's the procedure for this I can't find anything on the website.

People just send in the "cvs diff -u" or without CVS just a diff -u.

> The actual patch is trivial it's just a matter of add a 
> synchronized block in getNamespace as marked with ++ below, 
> and some suitable comments on synch policy.

That's the easy way.  :-)  But I was wondering if there could be an
optimization (it's important here, this code is called all the time). 
Like for example you could put "if not contains then add" in the sync
block and handle the return and the corresponding hash lookup outside
the block.  That'd shorten the crit section.  

Plus I was hoping you could run some tests with the code you have that
you thought would expose this problem, and make sure you can reproduce
the problem before and not after.

-jh-

From omenred at yahoo.com  Fri Sep 22 08:37:30 2000
From: omenred at yahoo.com (Omen Red)
Date: Fri Aug  6 17:05:01 2004
Subject: [jdom-interest] element's getSerializableForm() status.
Message-ID: <20000922153730.20939.qmail@web2104.mail.yahoo.com>

Hi,
Does anybody know what is status getSerializableForm()
function? Right now it throws RuntimeException. Some
time ago I heard that this function is going to be
deprecated, and it was suggested to use XMLOutputter
instead. The XMLOutputter is ok as for me, but it can
handle only org.jdom.Document.

So the question is: "is there any posibility to get
XML text from org.jdom.Element object ?"

thanx in advance,
om.

__________________________________________________
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/

From jools at jools.org  Fri Sep 22 09:25:47 2000
From: jools at jools.org (Jools Enticknap)
Date: Fri Aug  6 17:05:01 2004
Subject: [jdom-interest] static data needs to be thread data for  
 multithreaded applications
References: <AF7105DDF744D311A7DF005004B07090C6DF4C@exchange1.gtl.com> <39CB77D5.E221778C@acm.org>
Message-ID: <39CB880B.32B55D61@jools.org>

> > The actual patch is trivial it's just a matter of add a
> > synchronized block in getNamespace as marked with ++ below,
> > and some suitable comments on synch policy.
> 
> That's the easy way.  :-)  But I was wondering if there could be an
> optimization (it's important here, this code is called all the time).
> Like for example you could put "if not contains then add" in the sync
> block and handle the return and the corresponding hash lookup outside
> the block.  That'd shorten the crit section.

Before we go down this path, I'd like to see some benchmarks, and some
more reasoning.

Also, is there an external way of resolving this problem without having
to resort to putting synchronization into the code API ?

One approach might be to have separate classloaders for each 'read' 
thread. That way there would be more than one static namespace hash,
and no need to synchronize it internally.

--Jools

From Nick.Reeves at gtl.com  Fri Sep 22 09:57:35 2000
From: Nick.Reeves at gtl.com (Nick Reeves)
Date: Fri Aug  6 17:05:01 2004
Subject: [jdom-interest] static data needs to be thread data for   mul
	tithreaded applications
Message-ID: <AF7105DDF744D311A7DF005004B07090C6DF52@exchange1.gtl.com>

The class could either keep the last Namespace returned or an array of
recently returned
ones indexed by abs(key.hashCode() % length), and only go onto doing the
full version involving syncronization if this failed.

> > > The actual patch is trivial it's just a matter of add a
> > > synchronized block in getNamespace as marked with ++ below,
> > > and some suitable comments on synch policy.
> > 
> > That's the easy way.  :-)  But I was wondering if there could be an
> > optimization (it's important here, this code is called all 
> the time).
> > Like for example you could put "if not contains then add" 
> in the sync
> > block and handle the return and the corresponding hash 
> lookup outside
> > the block.  That'd shorten the crit section.
> 
> Before we go down this path, I'd like to see some benchmarks, and some
> more reasoning.
> 
> Also, is there an external way of resolving this problem 
> without having
> to resort to putting synchronization into the code API ?

From bob at accurev.com  Fri Sep 22 10:16:09 2000
From: bob at accurev.com (bob)
Date: Fri Aug  6 17:05:01 2004
Subject: [jdom-interest] static data needs to be thread data for   multithreaded applications
In-Reply-To: <39CB880B.32B55D61@jools.org>
Message-ID: <Pine.LNX.3.96.1000922131443.13763D-100000@exeter.exeter.org>

I may be completely off-base with regards to the Namespace improvements,
but if the Document/Element tree maintains the actual mappings, or
references to the mappings, I don't understand how threads can be a problem.

Even if we maintain the mappings statically, there still only needs to be
a single Namespace object mapping foo->http://foo.org/, across all threads,
right?

I guess I'm just missing the point.

	-bob

On Fri, 22 Sep 2000, Jools Enticknap wrote:

> 
> > > The actual patch is trivial it's just a matter of add a
> > > synchronized block in getNamespace as marked with ++ below,
> > > and some suitable comments on synch policy.
> > 
> > That's the easy way.  :-)  But I was wondering if there could be an
> > optimization (it's important here, this code is called all the time).
> > Like for example you could put "if not contains then add" in the sync
> > block and handle the return and the corresponding hash lookup outside
> > the block.  That'd shorten the crit section.
> 
> Before we go down this path, I'd like to see some benchmarks, and some
> more reasoning.
> 
> Also, is there an external way of resolving this problem without having
> to resort to putting synchronization into the code API ?
> 
> One approach might be to have separate classloaders for each 'read' 
> thread. That way there would be more than one static namespace hash,
> and no need to synchronize it internally.
> 
> --Jools
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
> 


From alan.quinton at autodesk.com  Fri Sep 22 12:21:37 2000
From: alan.quinton at autodesk.com (alan.quinton@autodesk.com)
Date: Fri Aug  6 17:05:01 2004
Subject: [jdom-interest] Attribute names and namespaces in JDOM
Message-ID: <F1373094C975D211A56100805FE6ED44044A8165@hqmsgsrf01.autodesk.com>

Is it correct for attribute names with no prefix to get associated with the value of the "xmlns=" in the first element of the document?

I have a schema like:

<xsd:schema xmlns:xsd="http://www.w3.org/1999/XMLSchema" targetNamespace="http://www.w3.org/namespace/" xmlns="http://www.w3.org/namespace/">
	<!-- data types -->
	<xsd:simpleType name="BaselineShiftValueType" base="xsd:string"/>
</xsd:schema>

and when I call element.getAttribute("name") on the xsd:simpleType element this throws a NoSuchAttribute exception. This seems incorrect to me...specifically that the "" prefix should be associated with a URI for attribute names. If it is correct it seems inconvenient. Am I totally off the mark here?

Thanks in advance, 
Alan Quinton
Software Engineer
Autodesk, Inc.


From boxer at ymx.sita.int  Fri Sep 22 16:54:25 2000
From: boxer at ymx.sita.int (Eddy Boxerman)
Date: Fri Aug  6 17:05:01 2004
Subject: [jdom-interest] Jar Creation Problem: NoClassDefFoundError
Message-ID: <39CBF130.8012888E@ymx.sita.int>

Hi,

I've downloaded and built jdom-b4.zip. I wrote a very simple applet
(found below) to test my installation, which I can compile and execute.
But when I try to build a jar file, I get the message:
"java.lang.NoClassDefFoundError: org/jdom/Namespace".

I'd greatly appreciate if anyone could suggest what I've done wrong.

Thanks,
Eddy

code:
-----

import java.awt.*;
import javax.swing.*;
import org.jdom.Element;

public class JApplet1 extends JApplet
{
 public void init()
 {
  getContentPane().setLayout(null);
  setSize(426,266);
  Element elem = new Element("root");
 }
}



From jozart at csi.com  Fri Sep 22 20:30:59 2000
From: jozart at csi.com (Joseph Bowbeer)
Date: Fri Aug  6 17:05:01 2004
Subject: [jdom-interest] Re: static data needs to be thread data for multithreaded applications
Message-ID: <001401c0250e$b75bcaf0$258a7cce@REPLICANT>

The subject seems to suggest that the solution would be (1) to use
ThreadLocal data for namespaces and other data that is currently static.
ThreadLocal is a Java2 feature.  Using thread local has these
disadvantages: you can end up duplicating the cached data and the work
involved in creating it in each thread.

Other options appear to be: (2) synchronizing access to the static data
or (3) doing-away with the static data.

If (2) is the solution, my advice is to limit the critical section to
the smallest size possible, and then show that performance *is* a
problem before trying to do anything more clever.

As Bill Pugh says: "Using synchronization isn't that expensive, and it
serves as important and useful documentation to programmers about the
intended thread interactions in your code."

At a glance, I don't see how the critical section around namespaces can
be easily reduced...  As I pointed out before, most optimizations
designed to reduce synchronization in Java are just plain wrong,
including double-check locking:

 http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html

Option (3) has some nice properties, though - like compatibility with
garbage collection.  Can the data that is static now be moved into a
factory as instance data?

--
Joe Bowbeer




From engp9818 at nus.edu.sg  Sat Sep 23 01:02:11 2000
From: engp9818 at nus.edu.sg (Abhinav Tyagi)
Date: Fri Aug  6 17:05:01 2004
Subject: [jdom-interest] help wanted
Message-ID: <30A14FB41CC5D311854D00508B5EEF0206D7A0C4@exs23.ex.nus.edu.sg>

i have downloaded jdom-b4-src.zip file and extracted it to d:\download\
i set classpath as
set classpath=d:\download\jdom in the autoexec.bat file
When i tried to compile the sample file WarReader.java i am getting 13
errors stating "java 51:cannot resolve symbol: class Element"

it will be great if you could let me know (infact right from the begining)
as to how should I use jdom to communicate with xml documents. I like the
simplicity and intuitiveness of jdom classes but am bogged down by the
implementation problems.

thanks 

abhinav
 

From guru at edamame.stinky.com  Sat Sep 23 20:10:59 2000
From: guru at edamame.stinky.com (Alex Chaffee)
Date: Fri Aug  6 17:05:01 2004
Subject: [jdom-interest] static data needs to be thread data for   multithreaded applications
In-Reply-To: <Pine.LNX.3.96.1000922131443.13763D-100000@exeter.exeter.org>; from bob@accurev.com on Fri, Sep 22, 2000 at 01:16:09PM -0400
References: <39CB880B.32B55D61@jools.org> <Pine.LNX.3.96.1000922131443.13763D-100000@exeter.exeter.org>
Message-ID: <20000923201059.F13533@edamame.stinky.com>

On Fri, Sep 22, 2000 at 01:16:09PM -0400, bob wrote:
> 
> I guess I'm just missing the point.
> 

Yup :-)

If two threads each add a new namespace at the exact same time, then
the *collection* object (which is static thus shared) will barf with
ConcurrentModificationError.

See my http://www.jguru.com/faq/Threads :-)

 - Alex


-- 
Alex Chaffee                       mailto:alex@jguru.com
jGuru - Java News and FAQs         http://www.jguru.com/alex/
Creator of Gamelan                 http://www.gamelan.com/
Founder of Purple Technology       http://www.purpletech.com/
Curator of Stinky Art Collective   http://www.stinky.com/

From c.boldenow at cytera.com  Sun Sep 24 09:53:06 2000
From: c.boldenow at cytera.com (Carey Boldenow)
Date: Fri Aug  6 17:05:01 2004
Subject: [jdom-interest] ID/IDREF
Message-ID: <000a01c02647$ee0348a0$268deed0@default>

Is it possible to select Elements based on their IDs/IDREFs using JDOM?

Thanks,
Carey Boldenow
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://jdom.org/pipermail/jdom-interest/attachments/20000924/8eaed7a8/attachment.htm
From bob at accurev.com  Sun Sep 24 08:45:09 2000
From: bob at accurev.com (bob)
Date: Fri Aug  6 17:05:01 2004
Subject: [jdom-interest] static data needs to be thread data for   multithreaded applications
In-Reply-To: <20000923201059.F13533@edamame.stinky.com>
Message-ID: <Pine.LNX.3.96.1000924114437.13763Z-100000@exeter.exeter.org>

Yah, I understand the neccesity for some synchronization,
but someone suggested ThreadLocal storage, which just 
baffled me.

	-bob


On Sat, 23 Sep 2000, Alex Chaffee wrote:

> On Fri, Sep 22, 2000 at 01:16:09PM -0400, bob wrote:
> > 
> > I guess I'm just missing the point.
> > 
> 
> Yup :-)
> 
> If two threads each add a new namespace at the exact same time, then
> the *collection* object (which is static thus shared) will barf with
> ConcurrentModificationError.
> 
> See my http://www.jguru.com/faq/Threads :-)
> 
>  - Alex
> 
> 
> -- 
> Alex Chaffee                       mailto:alex@jguru.com
> jGuru - Java News and FAQs         http://www.jguru.com/alex/
> Creator of Gamelan                 http://www.gamelan.com/
> Founder of Purple Technology       http://www.purpletech.com/
> Curator of Stinky Art Collective   http://www.stinky.com/
> 


From bob at accurev.com  Sun Sep 24 11:44:09 2000
From: bob at accurev.com (bob)
Date: Fri Aug  6 17:05:01 2004
Subject: [jdom-interest] ID/IDREF
In-Reply-To: <000a01c02647$ee0348a0$268deed0@default>
Message-ID: <Pine.LNX.3.96.1000924144255.13763f-100000@exeter.exeter.org>

On Sun, 24 Sep 2000, Carey Boldenow wrote:

> Is it possible to select Elements based on their IDs/IDREFs using JDOM?

This is something at least my XPath implementation *should* do someday.

I haven't figure out how, and dunno if I'll need support from the
JDOM library itself.  It requires access to the DTD/schema of the
document, as without that additional information, IDs do not
truly exist.

Thoughts?  

	-bob


From bob at accurev.com  Sun Sep 24 18:52:50 2000
From: bob at accurev.com (bob)
Date: Fri Aug  6 17:05:01 2004
Subject: [jdom-interest] getDocument() patch
Message-ID: <Pine.LNX.3.96.1000924214713.13763r-100000@exeter.exeter.org>


http://code.werken.com/document_patch.txt

Synopsis:

Removed isRootElement boolean flag, and replaced with a Document document
member.  Held only by the root element.  isRootElement() now tests against 
(this.document != null).

Removed setIsRootElement() and added setDocument() instead.

Added getDocument() which recurses to an element which isRootElement(),
and returns it's this.document, or null, if not a part of a well-formed
Document.

Patch against the CVS tree as of 9:45pm Eastern tonight.

It compiled, but I haven't really tested it.

btw, diff -u now includes, by default, the ant-modified
build scripts with EOL changes.  Blaugh.

	-bob



From ernst at jollem.com  Mon Sep 25 08:01:42 2000
From: ernst at jollem.com (Ernst de Haan)
Date: Fri Aug  6 17:05:01 2004
Subject: [jdom-interest] getDocument() patch
In-Reply-To: <Pine.LNX.3.96.1000924214713.13763r-100000@exeter.exeter.org>; from bob@accurev.com on Sun, Sep 24, 2000 at 09:52:50PM -0400
References: <Pine.LNX.3.96.1000924214713.13763r-100000@exeter.exeter.org>
Message-ID: <20000925170142.A3335@c187104187.telekabel.chello.nl>

Hi Bob,

An alternative solution would be to subclass Element. Name the subclass
RootElement, and give it the mentioned field of type Document. The
isRootElement() method of the superclass Element can be implemented as
returning false, while it is overloaded in the subclass RootElement to return
true.

The advantage of my suggested approach is mailly less memory consumption. A
simple pointer (the reference to a Document) is 4 bytes (32 bits). For a large
XML tree this can make a considerable difference.

Just my 2 cts.

Ernst


bob wrote:
> 
> 
> http://code.werken.com/document_patch.txt
> 
> Synopsis:
> 
> Removed isRootElement boolean flag, and replaced with a Document document
> member.  Held only by the root element.  isRootElement() now tests against 
> (this.document != null).
> 
> Removed setIsRootElement() and added setDocument() instead.
> 
> Added getDocument() which recurses to an element which isRootElement(),
> and returns it's this.document, or null, if not a part of a well-formed
> Document.
> 
> Patch against the CVS tree as of 9:45pm Eastern tonight.
> 
> It compiled, but I haven't really tested it.
> 
> btw, diff -u now includes, by default, the ant-modified
> build scripts with EOL changes.  Blaugh.
> 
> 	-bob
> 
> 
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
> 

From Murray.Altheim at eng.sun.com  Mon Sep 25 12:04:34 2000
From: Murray.Altheim at eng.sun.com (Murray Altheim)
Date: Fri Aug  6 17:05:01 2004
Subject: [jdom-interest] ID/IDREF
References: <Pine.LNX.3.96.1000924144255.13763f-100000@exeter.exeter.org>
Message-ID: <39CFA1C2.FFD8E2CD@eng.sun.com>

bob wrote:
> 
> On Sun, 24 Sep 2000, Carey Boldenow wrote:
> 
> > Is it possible to select Elements based on their IDs/IDREFs using JDOM?
> 
> This is something at least my XPath implementation *should* do someday.
> 
> I haven't figure out how, and dunno if I'll need support from the
> JDOM library itself.  It requires access to the DTD/schema of the
> document, as without that additional information, IDs do not
> truly exist.
> 
> Thoughts?

You're correct in that without a schema, it's impossible to know which
attributes have been declared as IDs. But assuming that one does have a
schema, what I did in my parser/XPath implementation is simply to keep
a hashtable of all element-attribute pairs that are declared IDs, and
as I encounter them while parsing an instance, I add the new ID to a
second hashtable. I do a preliminary check to see if the ID already 
exists; if so, throw a uniqueness exception. I didn't find this approach
difficult. A lookup in the latter hashtable provides the node of the
element containing the desired ID value.

Murray

...........................................................................
Murray Altheim, SGML/XML Grease Monkey     <mailto:altheim&#64;eng.sun.com>
XML Technology Center
Sun Microsystems, 1601 Willow Rd., MS UMPK17-102, Menlo Park, CA 94025

      In the evening
      The rice leaves in the garden
      Rustle in the autumn wind
      That blows through my reed hut.  -- Minamoto no Tsunenobu

From bob at accurev.com  Mon Sep 25 12:47:00 2000
From: bob at accurev.com (bob)
Date: Fri Aug  6 17:05:01 2004
Subject: [jdom-interest] ID/IDREF
In-Reply-To: <39CFA1C2.FFD8E2CD@eng.sun.com>
Message-ID: <Pine.LNX.3.96.1000925154221.13763x-100000@exeter.exeter.org>

Yah, I figured something like that would work.

My only current sticking point is then having to parse
the DTD/schema to get the information as which attributes
are indeed ID attributes.  Any hints? ;) 

I really don't want to write a DTD parser, and XML-schema
is too much in flux for me to bother with at the moment. ;)
Especially since both are theoretically parsed already by
Xerces (or whichever XML parser is in use to generate the
JDOM, if any.)

Anyhow, id() will probably be amongst the last things I
implement.  (I'm working on following[-sibling] and
preceeding[-sibling] axes currently, which will make
it almost completely done.)

As far as duplicates, I don't think it's exceptional if there
isn't uniqueness.  Doesn't The Standard simply say first-one-wins?

btw, Murrary, is your XPath implementation built on JDOM?
Regardless, is it available as source for perusal?

	-bob


On Mon, 25 Sep 2000, Murray Altheim wrote:

> bob wrote:
> > 
> > On Sun, 24 Sep 2000, Carey Boldenow wrote:
> > 
> > > Is it possible to select Elements based on their IDs/IDREFs using JDOM?
> > 
> > This is something at least my XPath implementation *should* do someday.
> > 
> > I haven't figure out how, and dunno if I'll need support from the
> > JDOM library itself.  It requires access to the DTD/schema of the
> > document, as without that additional information, IDs do not
> > truly exist.
> > 
> > Thoughts?
> 
> You're correct in that without a schema, it's impossible to know which
> attributes have been declared as IDs. But assuming that one does have a
> schema, what I did in my parser/XPath implementation is simply to keep
> a hashtable of all element-attribute pairs that are declared IDs, and
> as I encounter them while parsing an instance, I add the new ID to a
> second hashtable. I do a preliminary check to see if the ID already 
> exists; if so, throw a uniqueness exception. I didn't find this approach
> difficult. A lookup in the latter hashtable provides the node of the
> element containing the desired ID value.
> 
> Murray
> 
> ...........................................................................
> Murray Altheim, SGML/XML Grease Monkey     <mailto:altheim&#64;eng.sun.com>
> XML Technology Center
> Sun Microsystems, 1601 Willow Rd., MS UMPK17-102, Menlo Park, CA 94025
> 
>       In the evening
>       The rice leaves in the garden
>       Rustle in the autumn wind
>       That blows through my reed hut.  -- Minamoto no Tsunenobu
> 


From Murray.Altheim at eng.sun.com  Mon Sep 25 13:08:13 2000
From: Murray.Altheim at eng.sun.com (Murray Altheim)
Date: Fri Aug  6 17:05:02 2004
Subject: [jdom-interest] ID/IDREF
References: <Pine.LNX.3.96.1000925154221.13763x-100000@exeter.exeter.org>
Message-ID: <39CFB0AD.F4E9F5FD@eng.sun.com>

bob wrote:
> 
> Yah, I figured something like that would work.
> 
> My only current sticking point is then having to parse
> the DTD/schema to get the information as which attributes
> are indeed ID attributes.  Any hints? ;)
> 
> I really don't want to write a DTD parser, and XML-schema
> is too much in flux for me to bother with at the moment. ;)
> Especially since both are theoretically parsed already by
> Xerces (or whichever XML parser is in use to generate the
> JDOM, if any.)

The tough part of writing only a portion of a DTD parser for
me was getting correct the conditional sections, especially
nested ones. You need to parse parameter entity declarations to
catch the condsect keywords, too. You can't merely search 
through for ATTLISTs since you don't know which are active 
without correct processing of parameter entities and 
conditional sections. *But* if you do PEs, conditional sections
and ATTLISTs you've done all you need to grab the ID information.
ATTLISTs on their own are pretty simple. You could get the code
to do the PEs and condsects from an existing parser, say the
Sun or Xerces parser. It's in there.
 
> Anyhow, id() will probably be amongst the last things I
> implement.  (I'm working on following[-sibling] and
> preceeding[-sibling] axes currently, which will make
> it almost completely done.)

Once I got the basic DTD parser written, I actually enjoyed the
challenge of the XPath stuff.
 
> As far as duplicates, I don't think it's exceptional if there
> isn't uniqueness.  Doesn't The Standard simply say first-one-wins?

No, in a document instance, all IDs *must* be unique in a valid XML
document. In well-formed XML you have no IDs whatsoever. If you mean
duplicate attribute specifications in the DTD, then yes, first one
wins:

   <!ATTLIST  foo
       id   CDATA   #IMPLIED
   >
   <!ATTLIST  foo
       id   ID     #IMPLIED
   >

The type of 'id' above would be CDATA, but the below is a validation
error:

   <!DOCTYPE blah [
   <!ELEMENT blah  ( foo )*>
   <!ELEMENT foo  EMPTY >
   <!ATTLIST foo
        id   ID    #IMPLIED
   >
   ]>
   <blah>
     <foo id="burger"/>
     <foo id="burger"/>
   </blah>

> btw, Murray, is your XPath implementation built on JDOM?
> Regardless, is it available as source for perusal?

The XML parser project I wrote goes back several years and has been
used internally for various projects I've been involved with, mostly
DTD analysis (such as comparing SGML and DTDs, eg., HTML 4 and XHTML).
Since this wasn't written for an outside audience, isn't bulletproof,
isn't i18n-compatible (it only needs to parse DTDs in US ASCII), and 
there's no way I could support it, it's unavailable at this time. I
wrote in support for about 3/4 of an earlier XPath draft, and it 
involves a bunch of SAX API extensions I needed to truly analyse, 
alter, document and re-constitute DTDs from the parse. If I'd had 
time I probably could have provided some input into SAX2 based on
this experience, but like so many things I simply haven't had the 
cycles.
 
Murray

...........................................................................
Murray Altheim, SGML/XML Grease Monkey     <mailto:altheim&#64;eng.sun.com>
XML Technology Center
Sun Microsystems, 1601 Willow Rd., MS UMPK17-102, Menlo Park, CA 94025

      In the evening
      The rice leaves in the garden
      Rustle in the autumn wind
      That blows through my reed hut.  -- Minamoto no Tsunenobu

From wendy.liew at home.com  Sun Sep 24 13:32:20 2000
From: wendy.liew at home.com (Wendy Liew)
Date: Fri Aug  6 17:05:02 2004
Subject: [jdom-interest] org.w3c.dom.* not used in jdom
Message-ID: <NEBBKNALJKLKEIHLDBFMGEEICBAA.wendy.liew@home.com>

how come jdom creates its own set of document, etc classes
rather than providing an implementation to w3c spec classes....

thanks,
wendy

From Murray.Altheim at eng.sun.com  Mon Sep 25 13:42:57 2000
From: Murray.Altheim at eng.sun.com (Murray Altheim)
Date: Fri Aug  6 17:05:02 2004
Subject: [jdom-interest] ID/IDREF
References: <Pine.LNX.3.96.1000925154221.13763x-100000@exeter.exeter.org> <39CFB0AD.F4E9F5FD@eng.sun.com>
Message-ID: <39CFB8D1.7EEFCC69@eng.sun.com>

Murray Altheim wrote:
[...]
> The XML parser project I wrote goes back several years and has been
> used internally for various projects I've been involved with, mostly
> DTD analysis (such as comparing SGML and   DTDs, eg., HTML 4 and XHTML).
                                           ^ XML 

Sorry, just for clarification. I'm not sure if it'll be available as
part of the eventual XHTML distribution, but within the HTML WG I
provided output from this analysis tool. I will *eventually* release
the doctypes.org site, which will provide HTML output from the DTD
analysis similar to Earl Hood's old perlsgml (ie., dtd2html) project.

Ah, to have the time....

Murray

...........................................................................
Murray Altheim, SGML/XML Grease Monkey     <mailto:altheim&#64;eng.sun.com>
XML Technology Center
Sun Microsystems, 1601 Willow Rd., MS UMPK17-102, Menlo Park, CA 94025

      In the evening
      The rice leaves in the garden
      Rustle in the autumn wind
      That blows through my reed hut.  -- Minamoto no Tsunenobu

From jhunter at acm.org  Mon Sep 25 13:53:21 2000
From: jhunter at acm.org (Jason Hunter)
Date: Fri Aug  6 17:05:02 2004
Subject: [jdom-interest] getDocument() patch
References: <Pine.LNX.3.96.1000924214713.13763r-100000@exeter.exeter.org>
Message-ID: <39CFBB41.F594216F@acm.org>

> http://code.werken.com/document_patch.txt
> 
> Synopsis:
> 
> Removed isRootElement boolean flag, and replaced with a Document

Just integrated the patch.

> It compiled, but I haven't really tested it.

Oops, didn't notice that remark until I integrated the patch.  I
wouldn't have integrated it had I seen it.  Just did some minimal
testing myself and it looked OK.

BTW, Brett wrote this when we started talking about this:

> I'm OK with this, but I don't have the time to make the changes. 
> There would need to be changes in Element.java, PartialList.java, 
> and Document.java, as far as I can tell.

You didn't make any changed to PartialList.  Brett, do you want to make
clear what changes you'd see?  The problem probably is that if you get
the list of content for the document itself and add an element to it,
there needs to be a setDocument() called!

> btw, diff -u now includes, by default, the ant-modified
> build scripts with EOL changes.  Blaugh.

Agreed.  Blaugh.

-jh-

From jhunter at acm.org  Mon Sep 25 13:55:22 2000
From: jhunter at acm.org (Jason Hunter)
Date: Fri Aug  6 17:05:02 2004
Subject: [jdom-interest] getDocument() patch
References: <Pine.LNX.3.96.1000924214713.13763r-100000@exeter.exeter.org> <20000925170142.A3335@c187104187.telekabel.chello.nl>
Message-ID: <39CFBBBA.25597159@acm.org>

> An alternative solution would be to subclass Element. Name the 
> subclass RootElement
> ...
> The advantage of my suggested approach is mailly less memory 

I added a comment in Element.java pointing at this email in the archives
so if in the future we're ever needing to do memory cutting, we'll have
that idea on record.  Adding a subclass to save 4 bytes now would be a
definite premature optimization.

-jh-

From wendy.liew at home.com  Sun Sep 24 14:22:40 2000
From: wendy.liew at home.com (Wendy Liew)
Date: Fri Aug  6 17:05:02 2004
Subject: [jdom-interest] closing clause
Message-ID: <NEBBKNALJKLKEIHLDBFMOEEJCBAA.wendy.liew@home.com>

hi, i wonder if the following are equivalent
(and yes, an element with only an attribute...)

<name value="wendy"></name>

and 

<name value="wendy" />

thanks,
wendy

From jhunter at acm.org  Mon Sep 25 14:15:28 2000
From: jhunter at acm.org (Jason Hunter)
Date: Fri Aug  6 17:05:02 2004
Subject: [jdom-interest] org.w3c.dom.* not used in jdom
References: <NEBBKNALJKLKEIHLDBFMGEEICBAA.wendy.liew@home.com>
Message-ID: <39CFC070.DC8939FD@acm.org>

Wendy Liew wrote:
> 
> how come jdom creates its own set of document, etc classes
> rather than providing an implementation to w3c spec classes....

Because JDOM is not DOM.  DOM is one way of approaching the problem
(language neutral).  JDOM is another way (Java optimized).

Read http://jdom.org for more information.

-jh-

From jhunter at acm.org  Mon Sep 25 14:38:08 2000
From: jhunter at acm.org (Jason Hunter)
Date: Fri Aug  6 17:05:02 2004
Subject: [jdom-interest] closing clause
References: <NEBBKNALJKLKEIHLDBFMOEEJCBAA.wendy.liew@home.com>
Message-ID: <39CFC5C0.534EA9CE@acm.org>

Wendy Liew wrote:
> 
> hi, i wonder if the following are equivalent
> (and yes, an element with only an attribute...)
> 
> <name value="wendy"></name>
> 
> and
> 
> <name value="wendy" />

That's answered in every XML book and every XML introductory article.  I
suggest you do at least a little research before writing *two* mailing
lists with beginner questions.

-jh-

From bob at accurev.com  Mon Sep 25 14:58:53 2000
From: bob at accurev.com (bob)
Date: Fri Aug  6 17:05:02 2004
Subject: [jdom-interest] OT: XPath test-suite
Message-ID: <Pine.LNX.3.96.1000925175713.13763C-100000@exeter.exeter.org>

Slightly off-topic, but..

Is anyone aware of a canonical test-suite of documents/xpath-exprs
I could possibly borrow, to test my implementation against?

I'm currently doing arbitrary typing-monkey tests, which certainly
aren't exhaustive.

	-bob


From jhunter at acm.org  Mon Sep 25 15:00:08 2000
From: jhunter at acm.org (Jason Hunter)
Date: Fri Aug  6 17:05:02 2004
Subject: [jdom-interest] Beta5 candidate
Message-ID: <39CFCAE8.83EC67AC@acm.org>

I'm home all this week, and I propose we ship JDOM Beta5 ASAP before I
head out for another two weeks overseas.  So, do we have anything
pressing that would hold up the beta?  All I can think of is maybe the
getChild/getChildElement decision.  Is there anything else?

The last little detail then is how to structure the .zip/.tar.gz file. 
Specifically, where do we put the jdom.jar file and the src, and how do
we deal with the JDK 1.1 custom build.  One possibility looks like this:

Archive:  jdom-b5.zip
 Length    Date    Time    Name
 ------    ----    ----    ----
  71783  09-25-00  14:24   jdom-b5/build/jdom.jar
    662  09-25-00  14:24   jdom-b5/build.bat
    650  09-25-00  14:24   jdom-b5/build.sh
   9175  09-25-00  14:24   jdom-b5/build.xml
    402  09-25-00  14:24   jdom-b5/build11.bat
    442  09-25-00  14:24   jdom-b5/build11.sh
    379  09-25-00  14:24   jdom-b5/COMMITTERS.txt
    588  09-25-00  14:24   jdom-b5/etc/crypt.pl
   1827  09-25-00  14:24   jdom-b5/etc/replic.pl
 179136  09-25-00  14:24   jdom-b5/lib/ant.jar
    137  09-25-00  14:24   jdom-b5/lib/bin/antRun
 259265  09-25-00  14:24   jdom-b5/lib/collections.jar
   6291  09-25-00  14:24   jdom-b5/lib/collections.license
   3859  09-25-00  14:24   jdom-b5/lib/collections.readme
 787419  09-25-00  14:24   jdom-b5/lib/xerces.jar
   2526  09-25-00  14:24   jdom-b5/LICENSE.txt
   3215  09-25-00  14:24   jdom-b5/README.txt
     98  09-25-00  14:24   jdom-b5/samples/cdata.xml
   2370  09-25-00  14:24   jdom-b5/samples/contents.xml
   6495  09-25-00  14:24   jdom-b5/samples/Count.java
   6740  09-25-00  14:24   jdom-b5/samples/DOMBuilderDemo.java
   1134  09-25-00  14:24   jdom-b5/samples/fibo.xml
    354  09-25-00  14:24   jdom-b5/samples/inline.xml
    643  09-25-00  14:24   jdom-b5/samples/namespaces.xml
   5942  09-25-00  14:24   jdom-b5/samples/SAXBuilderDemo.java
   5969  09-25-00  14:24   jdom-b5/samples/Testing.java
   7408  09-25-00  14:24   jdom-b5/samples/WarReader.java
   1319  09-25-00  14:24   jdom-b5/samples/web.xml
  48816  09-25-00  14:24   jdom-b5/src/java/org/jdom/.#Element.java.1.28
   4743  09-25-00  14:24  
jdom-b5/src/java/org/jdom/adapters/AbstractDOMAdapter.java
   4540  09-25-00  14:24  
jdom-b5/src/java/org/jdom/adapters/DOMAdapter.java
   5985  09-25-00  14:24  
jdom-b5/src/java/org/jdom/adapters/OracleV1DOMAdapter.java
   5915  09-25-00  14:24  
jdom-b5/src/java/org/jdom/adapters/OracleV2DOMAdapter.java
   5917  09-25-00  14:24  
jdom-b5/src/java/org/jdom/adapters/ProjectXDOMAdapter.java
   8366  09-25-00  14:24  
jdom-b5/src/java/org/jdom/adapters/XercesDOMAdapter.java
   8507  09-25-00  14:24  
jdom-b5/src/java/org/jdom/adapters/XML4JDOMAdapter.java
  16451  09-25-00  14:24   jdom-b5/src/java/org/jdom/Attribute.java
   5863  09-25-00  14:24   jdom-b5/src/java/org/jdom/CDATA.java
   6199  09-25-00  14:24   jdom-b5/src/java/org/jdom/Comment.java
   3572  09-25-00  14:24  
jdom-b5/src/java/org/jdom/DataConversionException.java
   9074  09-25-00  14:24   jdom-b5/src/java/org/jdom/DocType.java
  18580  09-25-00  14:24   jdom-b5/src/java/org/jdom/Document.java
  49678  09-25-00  14:24   jdom-b5/src/java/org/jdom/Element.java
  13253  09-25-00  14:24   jdom-b5/src/java/org/jdom/Entity.java
   5362  09-25-00  14:24  
jdom-b5/src/java/org/jdom/IllegalAddException.java
   4335  09-25-00  14:24  
jdom-b5/src/java/org/jdom/IllegalDataException.java
   4493  09-25-00  14:24  
jdom-b5/src/java/org/jdom/IllegalNameException.java
   4232  09-25-00  14:24  
jdom-b5/src/java/org/jdom/IllegalTargetException.java
  15428  09-25-00  14:24  
jdom-b5/src/java/org/jdom/input/DOMBuilder.java
  30759  09-25-00  14:24  
jdom-b5/src/java/org/jdom/input/SAXBuilder.java
   6582  09-25-00  14:24   jdom-b5/src/java/org/jdom/JDOMException.java
  11852  09-25-00  14:24   jdom-b5/src/java/org/jdom/Namespace.java
  15327  09-25-00  14:24  
jdom-b5/src/java/org/jdom/output/DOMOutputter.java
   3021  09-25-00  14:24  
jdom-b5/src/java/org/jdom/output/SAXOutputter.java
  33080  09-25-00  14:24  
jdom-b5/src/java/org/jdom/output/XMLOutputter.java
  13374  09-25-00  14:24   jdom-b5/src/java/org/jdom/PartialList.java
  11710  09-25-00  14:24  
jdom-b5/src/java/org/jdom/ProcessingInstruction.java
  34754  09-25-00  14:24   jdom-b5/src/java/org/jdom/Verifier.java
   8045  09-25-00  14:24   jdom-b5/TODO.txt
 ------                    -------
1784041                    59     

Basically, clone the daily snapshot minus the "CVS" directories, and
include build/jdom.jar so people don't have to type "build".  This has
the nice advantage that it's ready for people to do new development, and
a "build" command replaces the jdom.jar we provided, so people are
unlikely to have classpath bugs where they point at the distributed JAR
and not the built JAR.  

For JDK 1.1 users, we need a solution too.  Maybe have
build/jdom-jdk11.jar?  The problem there is that a "build11" doesn't
replace that JAR.  Maybe we could have build11/jdom.jar and let
"build11" build to build11 (requiring some build.xml rework)?  Other
ideas from JDK 1.1 users?

-jh-

From pvg at c-c-s.com  Mon Sep 25 16:40:28 2000
From: pvg at c-c-s.com (Peter V. Gadjokov)
Date: Fri Aug  6 17:05:02 2004
Subject: [jdom-interest] Beta5 candidate
Message-ID: <704ECFDA88B3D311B5F000A0C959E5B601FC15@adobo.c2labs.com>

Could I get the serialization changes in? If so, how? I haven't had time to
write a test-suite but it does work, I get the same trees out that I
serialize. 

Thanks,

-pvg

-----Original Message-----
From: Jason Hunter [mailto:jhunter@acm.org]
Sent: Monday, September 25, 2000 3:00 PM
To: jdom-interest@jdom.org
Subject: [jdom-interest] Beta5 candidate


I'm home all this week, and I propose we ship JDOM Beta5 ASAP before I
head out for another two weeks overseas.  So, do we have anything
pressing that would hold up the beta?  All I can think of is maybe the
getChild/getChildElement decision.  Is there anything else?

The last little detail then is how to structure the .zip/.tar.gz file. 
Specifically, where do we put the jdom.jar file and the src, and how do
we deal with the JDK 1.1 custom build.  One possibility looks like this:

Archive:  jdom-b5.zip
 Length    Date    Time    Name
 ------    ----    ----    ----
  71783  09-25-00  14:24   jdom-b5/build/jdom.jar
    662  09-25-00  14:24   jdom-b5/build.bat
    650  09-25-00  14:24   jdom-b5/build.sh
   9175  09-25-00  14:24   jdom-b5/build.xml
    402  09-25-00  14:24   jdom-b5/build11.bat
    442  09-25-00  14:24   jdom-b5/build11.sh
    379  09-25-00  14:24   jdom-b5/COMMITTERS.txt
    588  09-25-00  14:24   jdom-b5/etc/crypt.pl
   1827  09-25-00  14:24   jdom-b5/etc/replic.pl
 179136  09-25-00  14:24   jdom-b5/lib/ant.jar
    137  09-25-00  14:24   jdom-b5/lib/bin/antRun
 259265  09-25-00  14:24   jdom-b5/lib/collections.jar
   6291  09-25-00  14:24   jdom-b5/lib/collections.license
   3859  09-25-00  14:24   jdom-b5/lib/collections.readme
 787419  09-25-00  14:24   jdom-b5/lib/xerces.jar
   2526  09-25-00  14:24   jdom-b5/LICENSE.txt
   3215  09-25-00  14:24   jdom-b5/README.txt
     98  09-25-00  14:24   jdom-b5/samples/cdata.xml
   2370  09-25-00  14:24   jdom-b5/samples/contents.xml
   6495  09-25-00  14:24   jdom-b5/samples/Count.java
   6740  09-25-00  14:24   jdom-b5/samples/DOMBuilderDemo.java
   1134  09-25-00  14:24   jdom-b5/samples/fibo.xml
    354  09-25-00  14:24   jdom-b5/samples/inline.xml
    643  09-25-00  14:24   jdom-b5/samples/namespaces.xml
   5942  09-25-00  14:24   jdom-b5/samples/SAXBuilderDemo.java
   5969  09-25-00  14:24   jdom-b5/samples/Testing.java
   7408  09-25-00  14:24   jdom-b5/samples/WarReader.java
   1319  09-25-00  14:24   jdom-b5/samples/web.xml
  48816  09-25-00  14:24   jdom-b5/src/java/org/jdom/.#Element.java.1.28
   4743  09-25-00  14:24  
jdom-b5/src/java/org/jdom/adapters/AbstractDOMAdapter.java
   4540  09-25-00  14:24  
jdom-b5/src/java/org/jdom/adapters/DOMAdapter.java
   5985  09-25-00  14:24  
jdom-b5/src/java/org/jdom/adapters/OracleV1DOMAdapter.java
   5915  09-25-00  14:24  
jdom-b5/src/java/org/jdom/adapters/OracleV2DOMAdapter.java
   5917  09-25-00  14:24  
jdom-b5/src/java/org/jdom/adapters/ProjectXDOMAdapter.java
   8366  09-25-00  14:24  
jdom-b5/src/java/org/jdom/adapters/XercesDOMAdapter.java
   8507  09-25-00  14:24  
jdom-b5/src/java/org/jdom/adapters/XML4JDOMAdapter.java
  16451  09-25-00  14:24   jdom-b5/src/java/org/jdom/Attribute.java
   5863  09-25-00  14:24   jdom-b5/src/java/org/jdom/CDATA.java
   6199  09-25-00  14:24   jdom-b5/src/java/org/jdom/Comment.java
   3572  09-25-00  14:24  
jdom-b5/src/java/org/jdom/DataConversionException.java
   9074  09-25-00  14:24   jdom-b5/src/java/org/jdom/DocType.java
  18580  09-25-00  14:24   jdom-b5/src/java/org/jdom/Document.java
  49678  09-25-00  14:24   jdom-b5/src/java/org/jdom/Element.java
  13253  09-25-00  14:24   jdom-b5/src/java/org/jdom/Entity.java
   5362  09-25-00  14:24  
jdom-b5/src/java/org/jdom/IllegalAddException.java
   4335  09-25-00  14:24  
jdom-b5/src/java/org/jdom/IllegalDataException.java
   4493  09-25-00  14:24  
jdom-b5/src/java/org/jdom/IllegalNameException.java
   4232  09-25-00  14:24  
jdom-b5/src/java/org/jdom/IllegalTargetException.java
  15428  09-25-00  14:24  
jdom-b5/src/java/org/jdom/input/DOMBuilder.java
  30759  09-25-00  14:24  
jdom-b5/src/java/org/jdom/input/SAXBuilder.java
   6582  09-25-00  14:24   jdom-b5/src/java/org/jdom/JDOMException.java
  11852  09-25-00  14:24   jdom-b5/src/java/org/jdom/Namespace.java
  15327  09-25-00  14:24  
jdom-b5/src/java/org/jdom/output/DOMOutputter.java
   3021  09-25-00  14:24  
jdom-b5/src/java/org/jdom/output/SAXOutputter.java
  33080  09-25-00  14:24  
jdom-b5/src/java/org/jdom/output/XMLOutputter.java
  13374  09-25-00  14:24   jdom-b5/src/java/org/jdom/PartialList.java
  11710  09-25-00  14:24  
jdom-b5/src/java/org/jdom/ProcessingInstruction.java
  34754  09-25-00  14:24   jdom-b5/src/java/org/jdom/Verifier.java
   8045  09-25-00  14:24   jdom-b5/TODO.txt
 ------                    -------
1784041                    59     

Basically, clone the daily snapshot minus the "CVS" directories, and
include build/jdom.jar so people don't have to type "build".  This has
the nice advantage that it's ready for people to do new development, and
a "build" command replaces the jdom.jar we provided, so people are
unlikely to have classpath bugs where they point at the distributed JAR
and not the built JAR.  

For JDK 1.1 users, we need a solution too.  Maybe have
build/jdom-jdk11.jar?  The problem there is that a "build11" doesn't
replace that JAR.  Maybe we could have build11/jdom.jar and let
"build11" build to build11 (requiring some build.xml rework)?  Other
ideas from JDK 1.1 users?

-jh-
_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com

From mfbaker at home.com  Mon Sep 25 16:46:47 2000
From: mfbaker at home.com (Michael F. Baker)
Date: Fri Aug  6 17:05:02 2004
Subject: [jdom-interest] Beta 5:  SaxBuilder constructor crashes Hunter & McLaughlin's code
Message-ID: <001201c0274a$de0b4e80$0a21120a@cemax.com>

I just downloaded JDOM beta 5, and the SaxBuilder constructor line below
crashes the application.  Anyone have any ideas?
Thanks!
- Mike

// This is code from the article "Easy Java/XML integration with JDOM, Part
1"
import java.io.*;
import org.jdom.*;
import org.jdom.input.*;
import org.jdom.output.*;

public class PrettyPrinter {
   public static void main(String[] args) {
        // Assume filename argument
        String filename = args[0];

        try {
            // Build the document with SAX and Xerces, no validation
            SAXBuilder builder = new SAXBuilder();  // CRASHES app!!
            // Create the document
            Document doc = builder.build(new File(filename));

            // Output the document, use standard formatter
            XMLOutputter fmt = new XMLOutputter();
            fmt.output(doc, System.out);
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}


From bob at accurev.com  Mon Sep 25 19:05:45 2000
From: bob at accurev.com (bob)
Date: Fri Aug  6 17:05:02 2004
Subject: [jdom-interest] more on namespaces && CDATA (and xpath, oh my!)
Message-ID: <Pine.LNX.3.96.1000925220315.13763J-100000@exeter.exeter.org>

Been reading more standards (Canonical XML this time)...

I think this W3C working draft explains that namespace declaratsions
can't be shifted around by the underlying XML processor, regardless of
semantics it thinks it understands.

Also, as an argument against CDATA, it says that the processor should replace
all CDATA sections with their character content.

http://www.w3.org/TR/xml-c14n

	-bob


From louisc at bu.edu  Mon Sep 25 20:32:42 2000
From: louisc at bu.edu (Louis Calisi)
Date: Fri Aug  6 17:05:02 2004
Subject: [jdom-interest] Stability of JDOM
Message-ID: <39D018DA.36ECAB62@bu.edu>

Hello:

    I am planning to build a fairly large J2EE application and I need to
use XML. After reading "Java and XML" I was hoping I could use JDOM. My
concerns are the stable of the API and how buggy is it? Do you guys
think it's ready for prime time or would I be better off work with
either SAX or DOM? I need to import and export XML documents.

Thanks,

Louis Calisi




From philip.nelson at omniresources.com  Mon Sep 25 20:48:28 2000
From: philip.nelson at omniresources.com (philip.nelson@omniresources.com)
Date: Fri Aug  6 17:05:02 2004
Subject: [jdom-interest] Re: static data needs to be thread data for m
	ultithreaded applications
Message-ID: <DF5018B3C986D11196FF0060089A903C2BFEC4@gbdev.omniresource.com>

On a related but different note, there is one other issue with the static
Namespace hashmap I have been wondering about.  In a long running use of the
Namespace class like a servlet engine or a SOAP processor, couldn't the
hashmap eventually get really large?  There is no way to remove a namespace
or mapping, nor can there be a way since multiple documents could share the
same namespace.

I realize for many users, even with heavy use, there will probably not be
lots of different namespaces.  But I do have a client doing a SOAP style
application where they really have no control over that.

What do you think?

From philip.nelson at omniresources.com  Mon Sep 25 20:58:57 2000
From: philip.nelson at omniresources.com (philip.nelson@omniresources.com)
Date: Fri Aug  6 17:05:02 2004
Subject: [jdom-interest] minor issue with Comment
Message-ID: <DF5018B3C986D11196FF0060089A903C2BFEC5@gbdev.omniresource.com>

While writing some tests for the test suite I noticed this in Comment.java
which seems a little inconsitent to me.  The constructor for a comment
checks the data for valid data with Verifier but setText doesn't.  Shouldn't
they both do the same thing?

Right now it's

    public Comment(String text) {
        String reason;
        if ((reason = Verifier.checkCommentData(text)) != null) {
            throw new IllegalDataException(text, "comment", reason);
        }

        this.text = text;
    }


    /**
     * <p>
     * This will set the value of the <code>Comment</code>.
     * </p>
     *
     * @param text <code>String</code> text for comment.
     * @return <code>Comment</code> - this Comment modified.
     */
    public Comment setText(String text) {
        this.text = text;
        return this;
    }

But maybe it should be something like ...

    public Comment(String text) {
	setText(text);
    }


    /**
     * <p>
     * This will set the value of the <code>Comment</code>.
     * </p>
     *
     * @param text <code>String</code> text for comment.
     * @return <code>Comment</code> - this Comment modified.
     */
    public Comment setText(String text) {
        String reason;
        if ((reason = Verifier.checkCommentData(text)) != null) {
            throw new IllegalDataException(text, "comment", reason);
        }

        this.text = text;
        return this;
    }

 

From liamw at home.com  Mon Sep 25 21:08:47 2000
From: liamw at home.com (Liam P. Walker)
Date: Fri Aug  6 17:05:02 2004
Subject: [jdom-interest] Obtaining an Eelement via attribute ID through JDOM?
Message-ID: <39D0214F.6D1000C8@home.com>

Some background:
================
I have an xml document and a DTD that defines the structure of that
document. 

I have an element with child element that is referred to in my xml using
an attribute of type ID (i.e. I'm referring to an existing element
within my document and only specifying the ID of that element).

e.g. 
<!-- Assume this is valid as I just typed it in and is not my real xml
I'm using.
-->

<elementA>
   <!-- the below element is the element I'm concerned with -->
   <elementB _idref="uniqueId"/> 
</elementA>

<!-- and here it is defined later in my xml 
   attribute _id has an attribute-type of ID
-->
<elementB _id="uniqueId"
   someAttributeA="a"
   someAttributeB="b">
   <subElementA/>
   <subElementB/>
   ...
</elementB>


The problem:
============
When you get the element elementB from its parent element elementA, you
cannot get at elementB's various attributes via getAttribute() and child
elements via getChild() (except the attribute named _idref defined as
attribute type IDREF).  i.e. Although you have an Element object, it
does not contain all the information which was defined for that element
elsewhere in my xml document.  (its not a reference or even a copy of
elementB)

I was hoping that the child element of elementA would be a reference to
the Element object elementB.  Doesn't this make sense - the xml refers
to the same data after all?

Assuming that I am correct is their a handy method that allows me to get
an Element from an xml document via its attribute of type ID so that I
can easily get what I want from this element?  I suppose I could create
this mechanism by figuring out which parser listener I need add myself
to and build a suitable index... 

I'd certainly rather a reference at this point unless someone can give
me a good reason to the contrary.


Thanks,
.maiL

*braces for impact*

From philip.nelson at omniresources.com  Mon Sep 25 21:12:01 2000
From: philip.nelson at omniresources.com (philip.nelson@omniresources.com)
Date: Fri Aug  6 17:05:02 2004
Subject: [jdom-interest] OT: XPath test-suite
Message-ID: <DF5018B3C986D11196FF0060089A903C2BFEC6@gbdev.omniresource.com>

> Slightly off-topic, but..
> 
> Is anyone aware of a canonical test-suite of documents/xpath-exprs
> I could possibly borrow, to test my implementation against?

It seems that a set of reference documents to test the various builders
makes sense too.  And it seems like this *ought* to be out there.  Any
ideas?

From jhunter at collab.net  Mon Sep 25 22:26:22 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:05:02 2004
Subject: [jdom-interest] more on namespaces && CDATA (and xpath, oh my!)
References: <Pine.LNX.3.96.1000925220315.13763J-100000@exeter.exeter.org>
Message-ID: <39D0337E.D30DDE62@collab.net>

> Been reading more standards (Canonical XML this time)...

That's the nice thing about XML.  As much reading as you have time for. 
:-)

> I think this W3C working draft explains that namespace declaratsions
> can't be shifted around by the underlying XML processor, regardless of
> semantics it thinks it understands.
> 
> Also, as an argument against CDATA, it says that the processor should
> replace all CDATA sections with their character content.

Canonical XML deals with the question of how to decide if two docs are
"logically equivalent".  It saying you ignore CDATA when testing doesn't
mean that we shouldn't have CDATA.

-jh-

From jhunter at collab.net  Mon Sep 25 22:53:16 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:05:02 2004
Subject: [jdom-interest] Re: static data needs to be thread data for 
 multithreaded applications
References: <DF5018B3C986D11196FF0060089A903C2BFEC4@gbdev.omniresource.com>
Message-ID: <39D039CC.EEB18053@collab.net>

> In a long running use of the Namespace class like a servlet engine 
> or a SOAP processor, couldn't the hashmap eventually get really 
> large?  

Yep.  Weak references would come to the rescue.  I added a note in the
code to mark this as a future possibility.  (I'm postponing action
because it's potentially a lot of code and testing in an area that's
been changing, and because weak refs don't work in JDK 1.1.)

-jh-

From jacebo at essi.es  Tue Sep 26 03:25:04 2000
From: jacebo at essi.es (Jorge Acebo)
Date: Fri Aug  6 17:05:02 2004
Subject: [jdom-interest] Problem with getChild()
Message-ID: <39D07980.BC0C3937@essi.es>

Hello.

I have an xml document that begins like this:

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE record SYSTEM "IMS_METADATAv1p1.dtd">
<record xmlns="http://www.imsproject.org/metadata/">
 <metametadata>
      <catalogentry>
           <catalogue></catalogue>
      </catalogentry>
  </metametadata>
<general>
    .... etc...

and I have the next code to read the children of <record> element:

Element root = doc.getRootElement();
List a = root.getChildren();
Iterator i = a.iterator();
while ( i.hasNext() )
{
    Element e = (Element) i.next();
    System.out.println("Children: " + e.getName());
}

This works well, and list "metadata", "general", etc... But when I try
to acces to one child:

   Element e = root.getChild("metametadata");


getChild returns a null pointer.

Why?



-------------- next part --------------
A non-text attachment was scrubbed...
Name: jacebo.vcf
Type: text/x-vcard
Size: 203 bytes
Desc: Card for Jorge Acebo
Url : http://jdom.org/pipermail/jdom-interest/attachments/20000926/97707077/jacebo.vcf
From jhunter at collab.net  Mon Sep 25 23:19:09 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:05:02 2004
Subject: [jdom-interest] minor issue with Comment
References: <DF5018B3C986D11196FF0060089A903C2BFEC5@gbdev.omniresource.com>
Message-ID: <39D03FDD.FD7A387B@collab.net>

You're right.  Just checked in the fix.

-jh-

philip.nelson@omniresources.com wrote:
> 
> While writing some tests for the test suite I noticed this in Comment.java
> which seems a little inconsitent to me.  The constructor for a comment
> checks the data for valid data with Verifier but setText doesn't.  Shouldn't
> they both do the same thing?
> 
> Right now it's
> 
>     public Comment(String text) {
>         String reason;
>         if ((reason = Verifier.checkCommentData(text)) != null) {
>             throw new IllegalDataException(text, "comment", reason);
>         }
> 
>         this.text = text;
>     }
> 
>     /**
>      * <p>
>      * This will set the value of the <code>Comment</code>.
>      * </p>
>      *
>      * @param text <code>String</code> text for comment.
>      * @return <code>Comment</code> - this Comment modified.
>      */
>     public Comment setText(String text) {
>         this.text = text;
>         return this;
>     }
> 
> But maybe it should be something like ...
> 
>     public Comment(String text) {
>         setText(text);
>     }
> 
>     /**
>      * <p>
>      * This will set the value of the <code>Comment</code>.
>      * </p>
>      *
>      * @param text <code>String</code> text for comment.
>      * @return <code>Comment</code> - this Comment modified.
>      */
>     public Comment setText(String text) {
>         String reason;
>         if ((reason = Verifier.checkCommentData(text)) != null) {
>             throw new IllegalDataException(text, "comment", reason);
>         }
> 
>         this.text = text;
>         return this;
>     }
> 
> 
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com

From ctodd at alabanza.com  Tue Sep 26 04:01:34 2000
From: ctodd at alabanza.com (Chris Todd)
Date: Fri Aug  6 17:05:02 2004
Subject: [jdom-interest] license compatibility question
In-Reply-To: <DF5018B3C986D11196FF0060089A903C2BFEC5@gbdev.omniresource.com>
Message-ID: <NEBBIHEHKDMBPMCNJKNMGENKDGAA.ctodd@alabanza.com>

I am interested in using JDOM in some open-source development, but I wanted
to make sure the licenses were compatible.

The project I want to which I want to contribute uses the GPL, but I notice
that JDOM uses an Apache-style license.  Is this a problem because of the
viral nature of the GPL?  Namely, would using JDOM in a GPL app require JDOM
to also be GPL?  I hope not, because JDOM looks really great and I'm looking
forward to working with it.

Thank you in advance for your time in answering this question, and forgive
me if this comes up a lot, but the legalese of the various OSS licenses is
something I do not quite have a grip on yet.

Sincerest regards,
Chris Todd


From EGalluzzo at synchrony.net  Tue Sep 26 06:05:48 2000
From: EGalluzzo at synchrony.net (Galluzzo, Eric)
Date: Fri Aug  6 17:05:02 2004
Subject: [jdom-interest] Problem with getChild()
Message-ID: <51C6625F6F63D211853B0008C74C1A1EFA77E5@corp-exchg-001.synchrony.net>

> -----Original Message-----
> From: Jorge Acebo [mailto:jacebo@essi.es]
> 
> Hello.
> 
> I have an xml document that begins like this:
> 
> <?xml version="1.0" encoding="ISO-8859-1"?>
> <!DOCTYPE record SYSTEM "IMS_METADATAv1p1.dtd">
> <record xmlns="http://www.imsproject.org/metadata/">
>  <metametadata>
>       <catalogentry>
>            <catalogue></catalogue>
>       </catalogentry>
>   </metametadata>
> <general>
>     .... etc...
> 
> and I have the next code to read the children of <record> element:
> 
> Element root = doc.getRootElement();
> List a = root.getChildren();
> Iterator i = a.iterator();
> while ( i.hasNext() )
> {
>     Element e = (Element) i.next();
>     System.out.println("Children: " + e.getName());
> }
> 
> This works well, and list "metadata", "general", etc... But when I try
> to acces to one child:
> 
>    Element e = root.getChild("metametadata");
> 
> 
> getChild returns a null pointer.
> 
> Why?

Because getChild(String) will only retrieve children in the empty namespace,
not in the parent element's namespace.  You want getChild(String,
Namespace), which will get children in the given namespace (i.e.
Namespace.getNamespace ("http://www.imsproject.org/metadata/")).  This
stumped me too when I started using JDOM. :)  There has been discussion as
to whether this should be changed, but no real decision has been made.

    - Eric

From bob at accurev.com  Tue Sep 26 06:59:42 2000
From: bob at accurev.com (bob)
Date: Fri Aug  6 17:05:02 2004
Subject: [jdom-interest] OT: XPath test-suite
In-Reply-To: <DF5018B3C986D11196FF0060089A903C2BFEC6@gbdev.omniresource.com>
Message-ID: <Pine.LNX.3.96.1000926095802.5741B-100000@exeter.exeter.org>

> > Slightly off-topic, but..
> > 
> > Is anyone aware of a canonical test-suite of documents/xpath-exprs
> > I could possibly borrow, to test my implementation against?
> 
> It seems that a set of reference documents to test the various builders
> makes sense too.  And it seems like this *ought* to be out there.  Any
> ideas?

There's a project at SourceForge which is collecting XSLT test-cases,
and oasis-open has an XSL/XPath conformance comittee.  Currently
nothing has been released, though, I'll probably be working with
OASIS on the XPath testsuite.

	-bob


From guru at edamame.stinky.com  Tue Sep 26 17:08:20 2000
From: guru at edamame.stinky.com (Alex Chaffee)
Date: Fri Aug  6 17:05:02 2004
Subject: [jdom-interest] BeanMapper
Message-ID: <20000926170820.A9981@edamame.stinky.com>

Here's the BeanMapper.java source code. Add it to the
jdom-contrib/src/java/org/jdom/contrib/beans directory.

Also, a jdom-contrib/build.xml that loads in jakarta regexp.jar --
find it on the jakarta web site.

 - Alex


-- 
Alex Chaffee                       mailto:alex@jguru.com
jGuru - Java News and FAQs         http://www.jguru.com/alex/
Creator of Gamelan                 http://www.gamelan.com/
Founder of Purple Technology       http://www.purpletech.com/
Curator of Stinky Art Collective   http://www.stinky.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: org.jdom.contrib.beans.zip
Type: application/octet-stream
Size: 39444 bytes
Desc: not available
Url : http://jdom.org/pipermail/jdom-interest/attachments/20000926/c1fe2c74/org.jdom.contrib.beans.obj
-------------- next part --------------
<!-- ===========================================================================


Introduction
============

To Be Written


Installing the build tools
==========================

For instructions on JDOM use of Ant see the build.xml find in the "jdom"
module (../jdom).

Build targets
=============

These are the meaningful targets for this build file:

 - package [default] -> creates ./build/jdom-contrib.jar
 - compile -> compiles the contributed source code
 - samples -> compiles the contributed samples
 - javadoc -> generates the API documentation in ./build/javadocs
 - clean -> restores the distribution to its original and clean state

-->

<project default="package" basedir=".">

  <!-- =================================================================== -->
  <!-- Initialization target                                               -->
  <!-- =================================================================== -->
  <target name="init">
    <tstamp/>
    <property name="Name" value="JDOM Contributions"/>
    <property name="name" value="jdom-contrib"/>
    <property name="version" value="1.0 prerelease"/>
    <property name="year" value="2000"/>

    <echo message="----------- ${Name} ${version} [${year}] ------------"/>

    <property name="build.compiler" value="classic"/>
    <property name="debug" value="on"/>
    <property name="optimize" value="on"/>
    <property name="deprecation" value="on"/>

    <property name="src.dir" value="./src/java"/>
    <property name="samples.dir" value="./samples"/>
    <property name="lib.dir" value="./lib"/>
    <property name="packages" value="org.jdom.*"/>

    <property name="build.dir" value="./build"/>
    <property name="build.src" value="./build/src"/>
    <property name="build.dest" value="./build/classes"/>
    <property name="build.javadocs" value="./build/apidocs"/>

    <property name="xpath.parser.dir" value="${build.src}/org/jdom/contrib/xpath/parser/"/>

    <property name="dist.root" value="./dist"/>
    <property name="dist.dir" value="${dist.root}/${name}-${version}"/>

    <filter token="year" value="${year}"/>
    <filter token="version" value="${version}"/>
    <filter token="date" value="${TODAY}"/>
    <filter token="log" value="true"/>
    <filter token="verbose" value="true"/>

    <!-- JDK1.1 collections -->
    <property name="coll.import" value="com.sun.java.util.collections"/>
    <available classname="${coll.import}.Collection" property="coll.present"/>
  </target>

  <!-- =================================================================== -->
  <!-- Help on usage                                                       -->
  <!-- =================================================================== -->
  <target name="usage">
    <echo message=""/>
    <echo message=""/>
    <echo message="JDOM Build file"/>
    <echo message="-------------------------------------------------------------"/>
    <echo message=""/>
    <echo message=" available targets are:"/>
    <echo message=""/>
    <echo message="   package  --> generates the jdom-contrib.jar file (default)"/>
    <echo message="   compile  --> compiles the contributed source code"/>
    <echo message="   samples  --> compiles the contributed samples"/>
    <echo message="   javadoc  --> generates the API documentation (java 1.2 only)"/>
    <echo message="   clean    --> restores the distribution to its clean state"/>
    <echo message=""/>
    <echo message=" See the comments inside the build.xml file for more details."/>
    <echo message="-------------------------------------------------------------"/>
    <echo message=""/>
    <echo message=""/>
  </target>

  <!-- =================================================================== -->
  <!-- Prepares the build directory                                        -->
  <!-- =================================================================== -->
  <target name="prepare" depends="init">
    <mkdir dir="${build.dir}"/>
  </target>

  <!-- =================================================================== -->
  <!-- Prepares the source code                                            -->
  <!-- =================================================================== -->
  <target name="prepare-src" depends="prepare">
    <!-- create directories -->
    <mkdir dir="${build.src}"/>
    <mkdir dir="${build.dest}"/>

    <!-- copy src files -->
    <copydir src="${src.dir}"
             dest="${build.src}"
             filtering="on"/>

    <java fork="yes"
          classname="antlr.Tool"
          jvmargs="-classpath ${java.class.path}"
          args="-o ${xpath.parser.dir} ${xpath.parser.dir}/xpath.g"/>

    <java fork="yes"
          classname="antlr.Tool"
          jvmargs="-classpath ${java.class.path}"
          args="-o ${xpath.parser.dir} ${xpath.parser.dir}/xpath_lexer.g"/>

  </target>

  <!-- =================================================================== -->
  <!-- Does replacement on files for dealing with collections.             -->
  <!-- XXX The efficiency could be improved here; all replacements should  -->
  <!-- XXX happen during one read/write phase and only for files that have -->
  <!-- XXX changed.                                                        -->
  <!-- =================================================================== -->
  <target name="collections" if="coll.present" depends="prepare-src">
    <replace dir="${build.src}" includes="org/**"
             token="java.util.Collection" value="${coll.import}.Collection"/>
    <replace dir="${build.src}" includes="org/**"
             token="java.util.Map" value="${coll.import}.Map"/>
    <replace dir="${build.src}" includes="org/**"
             token="java.util.HashMap" value="${coll.import}.HashMap"/>
    <replace dir="${build.src}" includes="org/**"
             token="java.util.List" value="${coll.import}.List"/>
    <replace dir="${build.src}" includes="org/**"
             token="java.util.LinkedList" value="${coll.import}.LinkedList"/>
    <replace dir="${build.src}" includes="org/**"
             token="java.util.Iterator" value="${coll.import}.Iterator"/>
    <replace dir="${build.src}" includes="org/**"
             token="java.util.ArrayList" value="${coll.import}.ArrayList"/>
    <!-- The following replace handles the "import java.util.*" case by    -->
    <!-- adding an "import com.sun.java.util.collections.*" after it.      -->
    <!-- BTW, \u000a is the Unicode escape for a new line. (jhunter)       -->
    <replace dir="${build.src}" includes="org/**"
             token="java.util.*" 
             value="java.util.*;\u000aimport ${coll.import}.*"/>
  </target>

  <!-- =================================================================== -->
  <!-- Prepares the example code                                           -->
  <!-- =================================================================== -->
  <target name="prepare-samples" depends="prepare">
    <!-- create directories -->
    <mkdir dir="${build.src}"/>
    <mkdir dir="${build.dest}"/>

    <!-- copy src files -->
    <copydir src="${samples.dir}"
             dest="${build.src}"
             filtering="on"/>
  </target>

  <!-- =================================================================== -->
  <!-- Compiles the source directory                                       -->
  <!-- =================================================================== -->
  <target name="compile" depends="prepare-src,collections">
    <!-- Compile the Spitfire demo only if the Spitfire classes are found -->
    <available property="spitfire.present"
     classname="com.XML_Technologies.Spitfire.Parsers.Element" />
    <!-- Compile the JTree demo only if the Swing classes are found -->
    <available property="swing.present"
     classname="javax.swing.tree.DefaultMutableTreeNode" />
    <javac srcdir="${build.src}"
           destdir="${build.dest}"
           debug="${debug}"
           optimize="${optimize}">
      <exclude name="**/Spitfire*.java" unless="spitfire.present" />
      <exclude name="**/*JTree*.java" unless="swing.present" />
    </javac>
  </target>

  <!-- =================================================================== -->
  <!-- Compiles the samples directory                                       -->
  <!-- =================================================================== -->
  <target name="samples" depends="prepare-samples">
    <!-- Compile the Spitfire demo only if the Spitfire classes are found -->
    <available property="spitfire.present"
     classname="com.XML_Technologies.Spitfire.Parsers.Element" />
    <javac srcdir="${build.src}"
           destdir="${build.dest}"
           debug="${debug}"
           optimize="${optimize}">
      <exclude name="**/Spitfire*.java" unless="spitfire.present" />
    </javac>
  </target>

  <!-- =================================================================== -->
  <!-- Creates the class package                                           -->
  <!-- =================================================================== -->
  <target name="package" depends="compile">
    <fixcrlf srcdir="." includes="*.bat" cr="add"/>
    <fixcrlf srcdir="." includes="*.sh" cr="remove"/>
    <jar jarfile="${build.dir}/${name}.jar"
         basedir="${build.dest}"
         includes="org/**"/>
  </target>

  <!-- =================================================================== -->
  <!-- Creates the API documentation                                       -->
  <!-- =================================================================== -->
  <target name="javadoc" depends="prepare-src">
    <mkdir dir="${build.javadocs}"/>
    <javadoc packagenames="${packages}"
             sourcepath="${build.src}"
             destdir="${build.javadocs}"
             author="true"
             version="true"
             use="true"
             splitindex="true"
             noindex="false"
             windowtitle="${Name} API"
             doctitle="${Name}"
             bottom="Copyright &#169; ${year} Brett McLaughlin, Jason Hunter. All Rights Reserved."
    />
  </target>

  <!-- =================================================================== -->
  <!-- Clean targets                                                       -->
  <!-- =================================================================== -->
  <target name="clean" depends="init">
    <deltree dir="${build.dir}"/>
    <delete file="${docs.dir}/changes.xml"/>
    <delete file="${docs.dir}/todo.xml"/>
    <delete file="${docs.dir}/book.xml"/>
  </target>

  <target name="distclean" depends="clean">
    <deltree dir="${dist.root}"/>
    <delete file="${Name}-${version}.tar.gz"/>
    <delete file="${Name}-${version}.tar"/>
    <delete file="${Name}-${version}.zip"/>
  </target>

</project>

<!-- End of file -->
From jhunter at collab.net  Tue Sep 26 20:39:39 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:05:02 2004
Subject: [jdom-interest] license compatibility question
References: <NEBBIHEHKDMBPMCNJKNMGENKDGAA.ctodd@alabanza.com>
Message-ID: <39D16BFB.B1B93304@collab.net>

> I am interested in using JDOM in some open-source development, but 
> I wanted to make sure the licenses were compatible.
> 
> The project I want to which I want to contribute uses the GPL, but 
> I notice that JDOM uses an Apache-style license.  Is this a 
> problem because of the viral nature of the GPL?  Namely, would 
> using JDOM in a GPL app require JDOM to also be GPL?  

JDOM uses an Apache-style license but without the credit clause, and
it's that clause which (at least primarily) keeps the Apache license
from being compatible with the GPL.  In that way the JDOM license is
actually similar the modified BSD license which does qualify as
GPL-compatible.  But it's actually an open question whether the Apache
license without the credit clause would be compatible, because the
Apache license and JDOM license have an additional restriction that
forks can't use the name "JDOM".  I heard rumors Stallman thinks that's
enough to blow the GPL compatibility.

Bottom line is it's not our call to make.  Stallman's opinion is well
respected with regard to GPL compatibility, and so it'd be interesting
to hear what his views are.  At the end of the day though it's really up
to the courts to decide (and none have ruled on anything involving the
GPL yet).  The people you should write to are the ones who wrote the GPL
code.  It's their license you're trying to be compatible with, not ours.

(As an aside, to everyone who is thinking of choosing a license: be
aware that using the GPL license means you can't mix with much of the
open source code out there include Apache code and MPL code.)

-jh-

From jhunter at collab.net  Tue Sep 26 20:49:15 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:05:02 2004
Subject: [jdom-interest] BeanMapper
References: <20000926170820.A9981@edamame.stinky.com>
Message-ID: <39D16E3B.49213DC0@collab.net>

Alex, don't you have commit privs to jdom-contrib still?  
contrib/beans is your baby.

-jh-

Alex Chaffee wrote:
> 
> Here's the BeanMapper.java source code. Add it to the
> jdom-contrib/src/java/org/jdom/contrib/beans directory.
> 
> Also, a jdom-contrib/build.xml that loads in jakarta regexp.jar --
> find it on the jakarta web site.
> 
>  - Alex
> 
> --
> Alex Chaffee                       mailto:alex@jguru.com
> jGuru - Java News and FAQs         http://www.jguru.com/alex/
> Creator of Gamelan                 http://www.gamelan.com/
> Founder of Purple Technology       http://www.purpletech.com/
> Curator of Stinky Art Collective   http://www.stinky.com/
> 
>   ------------------------------------------------------------------------
>                                  Name: org.jdom.contrib.beans.zip
>    org.jdom.contrib.beans.zip    Type: Zip Compressed Data (application/x-zip-compressed)
>                              Encoding: base64
> 
>    build.xmlName: build.xml
>             Type: Plain Text (text/plain)

From jhunter at collab.net  Tue Sep 26 23:55:36 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:05:02 2004
Subject: [jdom-interest] Beta 5:  SaxBuilder constructor crashes Hunter & 
 McLaughlin's code
References: <001201c0274a$de0b4e80$0a21120a@cemax.com>
Message-ID: <39D199E8.C99466CA@collab.net>

> I just downloaded JDOM beta 5, and the SaxBuilder constructor 
> line below crashes the application.  Anyone have any ideas?
> Thanks!
> - Mike

What *exactly* does "crashes the app" mean?

-jh-

From jhunter at collab.net  Wed Sep 27 00:02:15 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:05:02 2004
Subject: [jdom-interest] Beta5 candidate
References: <704ECFDA88B3D311B5F000A0C959E5B601FC15@adobo.c2labs.com>
Message-ID: <39D19B77.FFA2977A@collab.net>

> Could I get the serialization changes in? If so, how? I haven't 
> had time to write a test-suite but it does work, I get the same 
> trees out that I serialize.

Well, I wouldn't want to hold up beta5 for those changes.  We're simply
too desperate to have a new milestone.  On the other hand, getting them
into beta5 gives us an opportunity to test how well we migrate to
beta6.  Exactly how far along are you?  How substantial is the patch?

-jh-

From pvg at c-c-s.com  Wed Sep 27 00:22:03 2000
From: pvg at c-c-s.com (Peter V. Gadjokov)
Date: Fri Aug  6 17:05:02 2004
Subject: [jdom-interest] (no subject)
Message-ID: <704ECFDA88B3D311B5F000A0C959E5B601FC19@adobo.c2labs.com>

>Well, I wouldn't want to hold up beta5 for those changes.  We're simply
>too desperate to have a new milestone.  On the other hand, getting them
>into beta5 gives us an opportunity to test how well we migrate to
>beta6.  

Yep, I'd like to see it tested but no, I do not want to hold up a release.
As an aside, perhaps it's worth considering having somewhat more frequent
beta releases - the 'get it from cvs' is a very frequent response to bug
reports. 

>Exactly how far along are you?  How substantial is the patch?

I'm done, I've been sitting on it for a bit (since I sent out those perf.
numbers). The patch is small, writeObject and readObject methods are added
to all stored classes. I've tweaked Namespace a bit for better performance
but I'll take those changes out for the time being, the whole class is
likely to be rewritten by someone soon anyway. 
The only other changes are a SerializationUtils class with a couple of
static methods to reuse the custom serialization of Namespace and List. Oh
and I've abstracted the lazy instantiation of the content and attribute
lists in Element to two private methods since the constant repetition of new
LinkedList() all over Element somewhat defeats the purpose of declaring the
ivar List. That change is also fair game for killing if it seems
inappropriate. That's it. Should I just mail c-diffs to the list? 

-pvg

From jhunter at collab.net  Wed Sep 27 00:45:55 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:05:02 2004
Subject: [jdom-interest] Re:
References: <704ECFDA88B3D311B5F000A0C959E5B601FC19@adobo.c2labs.com>
Message-ID: <39D1A5B3.F9CA9B5E@collab.net>

> As an aside, perhaps it's worth considering having somewhat 
> more frequent beta releases - the 'get it from cvs' is a very 
> frequent response to bug reports.

Exactly!  That's why I'm not holding up this one any.

> Should I just mail c-diffs to the list?

Yep.  Make sure the utils class is package protected.  (Even at that
it's unfortunate we'd need another class, even a support class, for
people to see in the package.  Any way to do it elegantly without the
extra class?)

-jh-

From pvg at c-c-s.com  Wed Sep 27 01:17:20 2000
From: pvg at c-c-s.com (Peter V. Gadjokov)
Date: Fri Aug  6 17:05:02 2004
Subject: [jdom-interest] Beta5 candidate
Message-ID: <704ECFDA88B3D311B5F000A0C959E5B601FC1A@adobo.c2labs.com>

>Yep.  Make sure the utils class is package protected.  (Even at that
>it's unfortunate we'd need another class, even a support class, for
>people to see in the package.  Any way to do it elegantly without the
>extra class?)

I've put it in a org.jdom.util package but that's easy to change to org.jdom
and package protect it if that goes down better. It's not really a class,
just a couple of global functions. Their functionality can be explicitly cut
and pasted in the 3-5 places in which it is used. That's not 'elegant' in my
book but I'm not religious about it, I can make that change too, it will
just be a little more annoying to maintain in the future. 

Here's what it looks like - 

public class SerializationUtils
{
    public static void writeList(List list, ObjectOutputStream out)
        throws IOException
    [...] 
    public static List readList(ObjectInputStream in)
        throws IOException, ClassNotFoundException
    [...]	
    public static void writeNamespace(Namespace ns, ObjectOutputStream out)
        throws IOException
    [...] 
    public static Namespace readNamespace(ObjectInputStream in)
        throws IOException, ClassNotFoundException
    [...]
}

And it gets called in places like this - Element.writeObject - 

    private void writeObject(ObjectOutputStream out) throws IOException {
        
        out.writeInt(JDOM_ELEMENT_SVER);
        out.writeObject(name);
        SerializationUtils.writeList(attributes, out);
        SerializationUtils.writeList(content, out);
        SerializationUtils.writeNamespace(namespace, out);
    }

I just grepped my tree, there are three call pairs from two classes to
write/read list and two call pairs from two classes to write/read namespace.
Let me know which way you'd prefer to see this go, I'll wrap it up and spew
to the list tonight (or shortly after I hear from you)

-pvg

From jhunter at collab.net  Wed Sep 27 01:40:09 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:05:02 2004
Subject: [jdom-interest] Beta5 candidate
References: <704ECFDA88B3D311B5F000A0C959E5B601FC1A@adobo.c2labs.com>
Message-ID: <39D1B269.116F26A@collab.net>

>     public static void writeList(List list, ObjectOutputStream out)
>         throws IOException
>     [...]
>     public static List readList(ObjectInputStream in)
>         throws IOException, ClassNotFoundException
>     [...]

Well, this could go in PartialList.

>     public static void writeNamespace(Namespace ns, ObjectOutputStream out)
>         throws IOException
>     [...]
>     public static Namespace readNamespace(ObjectInputStream in)
>         throws IOException, ClassNotFoundException
>     [...]
> }

And this probably really should go in Namespace -- let the class take
care of its own serialization.

Using PartialList that way is probably just slightly less elegant for
us, but easier on the new JDOM user, and it's evened out by having
Namespace do its own internal management which I like in general
anyway.  At least that's my 1:40am thinking.

-jh-

From pvg at c-c-s.com  Wed Sep 27 02:17:55 2000
From: pvg at c-c-s.com (Peter V. Gadjokov)
Date: Fri Aug  6 17:05:02 2004
Subject: [jdom-interest] Beta5 candidate
Message-ID: <704ECFDA88B3D311B5F000A0C959E5B601FC1B@adobo.c2labs.com>

>Well, this could go in PartialList.

It could, it doesn't quite belong there since it stores any kind of List.
I'm not 100% sure but I think PartialList messes with the contract of the
List interface in ways that if you actually used this method to store a
PartialList, you won't get the exact same thing back when you read it, in
certain cases.  But as I said, I'm not religious about it, it's a workable
solution, I'll go with it unless you've had a better 2:15am insight in the
interim. 

>And this probably really should go in Namespace -- let the class take
>care of its own serialization.

Yeah, that's a better way. I should have thought of it but I already had the
utils class when I added that method. The Namespace thing can be taken care
of by standard means (readResolve/writeReplace/ObjectInputValidation
trickery) but I don't think that works on 1.1. Package protected statics in
Namespace are practically as good and more compatible. I think we have
consensus then. 

I would be against holding up a b5 release to sort out the get Child/Element
issues. I think the API is likely to be affected by the next rev of
namespace handling. No matter what design we go with, it will have to be
able to represent namespace declarations, distinguish between namespace name
[info set term] and  namespace decal. and perhaps even be able to do
in-scope tests. Such changes seem significant enough to likely affect our
views and the practical details of the traversal methods.

I'm putting with something else right now (a little JDOM-based utility to
make graphviz[http://www.research.att.com/sw/tools/graphviz/]
pretty-pictures of XML docs, I'll make it available if anyone else has a use
for it) but I'll make the serialization changes sometime tonight and email
them out. Thanks for the feedback. 

-pvg


From pvg at c-c-s.com  Wed Sep 27 02:53:46 2000
From: pvg at c-c-s.com (Peter V. Gadjokov)
Date: Fri Aug  6 17:05:02 2004
Subject: [jdom-interest] Re: static data needs to be thread data for 
	multithreaded applications
Message-ID: <704ECFDA88B3D311B5F000A0C959E5B601FC1C@adobo.c2labs.com>

>Yep.  Weak references would come to the rescue.  I added a note in the
>code to mark this as a future possibility.  (I'm postponing action
>because it's potentially a lot of code and testing in an area that's
>been changing, and because weak refs don't work in JDK 1.1.)

My use of JDOM is also in server-world and I'd prefer to see a slightly
different direction - JDOM is a utility API so I think it should, as far as
possible, avoid making resource-management decisions for the API user and
when it does, it should provide hooks for as much control as feasible. In
the case of namespaces - assuming JDOM can one day tell between a namespace
name and a namespace declaration - Namespace declarations (or rather, their
prefix mappings) will probably be bound to a particular document so the
static data issue goes away there. If there is a big howl for memory sharing
between instances of docs with identical prefix mappings, the management of
that stuff can be opened up with an interface and you could optionally set a
prefix mapping manager delegate on docs. As to namespace names, I can't see
a good reason to keep these as global data either. There is no reason to go
through hoops to steal some CPU and save me some memory so I can do an
identity (==) comparison between namespace names. The comparison can be
optimized so it rarely has to do a full string comparison (and the URI
strings themselves can be interned for ==). For the memory-conscious, a
NamespaceName.intern() can be added. 

Short'n'sweet - the static-data/sync problem is partially exacerbated by the
lack of separation between namespace name and namespace declaration and the
centralized storage of things that may not need centralized management under
a better model. Weak references alone are not a good option for serious
server-side use -I might (well, I do) want better control than that (say, a
configurable, explicitly bounded LRU cache that is based on weak
references). 

-pvg

From traversw at innoforge.co.za  Wed Sep 27 03:56:01 2000
From: traversw at innoforge.co.za (Travers Waker)
Date: Fri Aug  6 17:05:02 2004
Subject: [jdom-interest] Iterator.remove() is calling a non-overloaded method to remove children from an element.
Message-ID: <005c01c02871$8c8f2220$1501a8c0@travers>

Hi.

Calling Element.getChildren() returns a "live" list that modifies the
original XML document tree.  Whatever list JDOM returns obiviously has
overloaded methods for List.remove(Element name) to unset the pointer this
elements parent Element and perform other similar JDOM-specific tasks.

However, when one get's an Iterator for this List (i.e.
Element.getChildren().iterator()), the Iterator.remove() method calls a
method of the underlying list that is not overloaded to update the internal
fields of Element (e.g Element.parent).  The following code illustrates the
problem: (The code just moves a child element from parent1 to parent2).

package tests.jdom;
import java.util.*;
import org.jdom.*;

class JdomListTest2 {

  public static void main(String[] args) throws Exception {

    Element parent1 = new Element("parent1");
    Element parent2 = new Element("parent2");

    parent1.addContent(new Element("child"));

    List list = parent1.getChildren();
    Iterator it = list.iterator();
    Element child = (Element)it.next();
    // list.remove(child);
    it.remove();

    parent2.addContent(child);

  }
}

The error generated is:

org.jdom.IllegalAddException: The element "child" could not be added as a
child of "parent2": The element already has an existing parent "parent1"
 at org.jdom.Element.addContent(Element.java:846)
 at tests.jdom.JdomListTest2.main(JdomListTest2.java:20)
Exception in thread "main"

If I uncomment "list.remove(child)" and comment out "it.remove()",
everything works as expected.  This is not as efficient as using
it.remove(), because list.remove(child) involves searching through the list
again for teh "child" element, even though the Iterator (it) is pointing to
exact location of child already!

Shouldn't be that hard to fix, but it would take a while to get familiar
with the JDOM code and CVS, so I think I'd better let someone who knows what
they're doing add support for Iterator.remove().

Thanks

Travers


From mengelhart at earthtrip.com  Wed Sep 27 06:24:12 2000
From: mengelhart at earthtrip.com (Michael Engelhart)
Date: Fri Aug  6 17:05:02 2004
Subject: [jdom-interest] Beta5 candidate
Message-ID: <200009270042.e8R0g5i10518@sm3.texas.rr.com>

Has the bug been fixed where attributes that have escaped string values get unescaped upon parsing the XML document for beta 5?  This has been driving me insane but it doesn't appear that it has been fixed as of yet.    Anyone know?

Mike

From philip.nelson at omniresources.com  Wed Sep 27 11:04:51 2000
From: philip.nelson at omniresources.com (philip.nelson@omniresources.com)
Date: Fri Aug  6 17:05:02 2004
Subject: [jdom-interest] Re: static data needs to be thread data for  
	multithreaded applications
Message-ID: <DF5018B3C986D11196FF0060089A903C2BFECD@gbdev.omniresource.com>


> My use of JDOM is also in server-world and I'd prefer to see 
> a slightly
> different direction - JDOM is a utility API so I think it 
> should, as far as
> possible, avoid making resource-management decisions for the 
> API user and
> when it does, it should provide hooks for as much control as 
> feasible. In
> the case of namespaces - assuming JDOM can one day tell 
> between a namespace
> name and a namespace declaration - Namespace declarations (or 
> rather, their
> prefix mappings) will probably be bound to a particular 
> document so the
> static data issue goes away there.

Are you all thinking about using the getDocument to find locate the home for
the namespaces and or prefix mappings?  At the time NameSpace was written,
there was a lot of discussion about the static hashtables but because nobody
wanted to maintain parent relationships, there was no way to put namespace
information in the Document for any given element.  It seems this has
changed since then.

> Short'n'sweet - the static-data/sync problem is partially 
> exacerbated by the
> lack of separation between namespace name and namespace 
> declaration and the
> centralized storage of things that may not need centralized 
> management under
> a better model. 

I apologize in advance but I don't understand what you mean by "lack of
separation between namespace name and namespace declaration".  I think that
the static variables in Namespace can't work on a server, or at least that
it's more compromises that it's worth.  It does work in what I think would
have to be the more common use case of many similar xml documents processed
by a server app.  My use case is a problem.  I would think that
serialization would be complicated as well.

From alan.quinton at autodesk.com  Wed Sep 27 12:03:27 2000
From: alan.quinton at autodesk.com (alan.quinton@autodesk.com)
Date: Fri Aug  6 17:05:02 2004
Subject: [jdom-interest] No access to namespaces?
Message-ID: <F1373094C975D211A56100805FE6ED44044A816B@hqmsgsrf01.autodesk.com>

Can anyone say why the B4 documentation provides access to the namespace mappings while the actual code does not? Functions such as getNamespaceURI(), getNamespaceMappings() are documented, but not implemented in the jar file, or the code? Were these removed for a reason?

I need to get the URI associated with the prefix "" in the document so that I can make a proper call to element.getAttribute(), I can't seem to find a way to get this information...

Thanks in advance,
-Alan

From pvg at c-c-s.com  Wed Sep 27 12:40:03 2000
From: pvg at c-c-s.com (Peter V. Gadjokov)
Date: Fri Aug  6 17:05:03 2004
Subject: [jdom-interest] Iterator.remove() is calling a non-overloaded
	 method to remove children from an element.
Message-ID: <704ECFDA88B3D311B5F000A0C959E5B601FC1E@adobo.c2labs.com>



>Shouldn't be that hard to fix, but it would take a while to get familiar
>with the JDOM code and CVS, so I think I'd better let someone who knows
what
>they're doing add support for Iterator.remove().

It might be a little harder to fix than it looks, most likely PartialList
will have to provide its own Iterator (or perhaps someone can write a
ListView-type class that does not replicate storage and is not so gory).
PartialList _does_ appear to override all the relevant methods and take care
of setting the parent to null. The trouble is that the ListIterator impl
inside LinkedList (the superclass of PartialList, the ListIterator impl is a
private class it defines) does not actually call LinkedList.remove(Object),
it calls 
LinkedList.remove(Entry)
which is a private method and does all the work. PartialList never gets a
chance to get a method in edgewise. This is a little tricky to see in a
debugger because the private method is inlined in the ListItr
implementation. It's also not completely obvious from a quick glance at the
source since the type declaration of the 'lastReturned' ivar is no longer
visible in one's editor window. Isn't overloading fun?

In any event, the fix is worth thinking about some. It is also an
interesting datapoint in the 'is Element a List' debate - neither the person
who wrote the class nor the people who use JDOM (myself included) ever made
use of the 'live list' functionality enough to notice the issue :)

-pvg



From jhunter at collab.net  Wed Sep 27 13:57:05 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:05:03 2004
Subject: [jdom-interest] Re: static data needs to be thread data for  
 multithreaded applications
References: <DF5018B3C986D11196FF0060089A903C2BFECD@gbdev.omniresource.com>
Message-ID: <39D25F21.31279371@collab.net>

> At the time NameSpace was written,
> there was a lot of discussion about the static hashtables but 
> because nobody wanted to maintain parent relationships, there was 
> no way to put namespace information in the Document for any 
> given element.  It seems this has changed since then.

Elements can still exist unattached to a Document.

-jh-

From jhunter at collab.net  Wed Sep 27 14:07:48 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:05:03 2004
Subject: [jdom-interest] Iterator.remove() is calling a non-overloadedmethod 
 to remove children from an element.
References: <704ECFDA88B3D311B5F000A0C959E5B601FC1E@adobo.c2labs.com>
Message-ID: <39D261A4.BD84A5F4@collab.net>

> It might be a little harder to fix than it looks, most 
> likely PartialList will have to provide its own Iterator 
> (or perhaps someone can write a ListView-type class that does 
. not replicate storage and is not so gory).

Yep.  It's not a trivial fix (thus it's in the TODO.txt file and not
already done in the code) but it's a pretty straightforward fix.  I
suspect you could wrap a PartialListIterator around the ListItr normally
returned, and have it remove the elt from the backing list and then let
ListItr do its normal thing.

-jh-

From pvg at c-c-s.com  Wed Sep 27 14:28:06 2000
From: pvg at c-c-s.com (Peter V. Gadjokov)
Date: Fri Aug  6 17:05:03 2004
Subject: [jdom-interest] Iterator.remove() is calling a non-overloaded
	method  to remove children from an element.
Message-ID: <704ECFDA88B3D311B5F000A0C959E5B601FC1F@adobo.c2labs.com>

>I suspect you could wrap a PartialListIterator around the ListItr normally
>returned, and have it remove the elt from the backing list and then let
>ListItr do its normal thing.

What's the difficulty in having a predicated (filtered) sub-list class that
is just a plain wrapper around a List (any List, not just a LinkedList) as
opposed to the strange wrapper'n'subclass beast that PartialList is?
PartialList strikes me as hard to follow and wasteful, I'm sure there is a
reason for it but I can't figure it out. 


-pvg

-----Original Message-----
From: Jason Hunter [mailto:jhunter@collab.net]
Sent: Wednesday, September 27, 2000 2:08 PM
To: Peter V. Gadjokov
Cc: 'Travers Waker'; jdom-interest@jdom.org
Subject: Re: [jdom-interest] Iterator.remove() is calling a
non-overloadedmethod to remove children from an element.


> It might be a little harder to fix than it looks, most 
> likely PartialList will have to provide its own Iterator 
> (or perhaps someone can write a ListView-type class that does 
. not replicate storage and is not so gory).

Yep.  It's not a trivial fix (thus it's in the TODO.txt file and not
already done in the code) but it's a pretty straightforward fix.  

-jh-

From pvg at c-c-s.com  Wed Sep 27 14:31:40 2000
From: pvg at c-c-s.com (Peter V. Gadjokov)
Date: Fri Aug  6 17:05:03 2004
Subject: [jdom-interest] Re: static data needs to be thread data for  
	 multithreaded applications
Message-ID: <704ECFDA88B3D311B5F000A0C959E5B601FC20@adobo.c2labs.com>

>Are you all thinking about using the getDocument to find locate the home
for
>the namespaces and or prefix mappings?  At the time NameSpace was written,
>there was a lot of discussion about the static hashtables but because
nobody
>wanted to maintain parent relationships, there was no way to put namespace
>information in the Document for any given element.  It seems this has
>changed since then.
[...]
>I apologize in advance but I don't understand what you mean by "lack of
>separation between namespace name and namespace declaration".  I think that
>the static variables in Namespace can't work on a server, or at least that
>it's more compromises that it's worth.  It does work in what I think would
>have to be the more common use case of many similar xml documents processed
>by a server app.  My use case is a problem.  I would think that
>serialization would be complicated as well.

By 'separation' I mean having separate classes that represent what the
infoset calls 'namespace name' (basically, just the URI, a globally unique
id that distinguished one namespace from another, regardless of document
context) and a namespace declaration (a namespace, with a document-specific
prefix used for serialization and a document specific scope). 

Namespace names need no centralized static storage. It could be useful if
you want to save memory and it allows identity comparison but the global
storage has other problems (concurrency issues, potential for unbounded
growth, etc). 

Namespace declarations are document-specific so they need no centralized
storage either. The prefix map could live in Document. I think you are
raising the issue of getting the Document if you only have an element -
typically, an Outputter that cares most about prefixes gets the Document so
it doesn't have the problem. The recent change to isRootElement, though,
allows for the addition of a trivial getDocument method on Element which
would simply walk the path to the root until it hits the root element, if
any, and then return the root element's document. 

So, what I'm talking about is this:

 - A Namespace (or NamespaceName) class that is just the URI. This class has
a fast .equals method but does not rely on identity comparison. A sync'ed
Namespace.intern() method can be provided to trade performance for memory,
potentially, the parser can have an option to intern every NamespaceName it
encounters. 

- A NamespaceDeclaration class that is typically stored in an Element. It
describes the binding of a prefix to a NamespaceName and the scope of the
Namespace (which is the inclusive scope of the Element). 

- Facilities on Document and/or Element that let you 
   - look up the NamespaceName given a prefix and a scope (Element)
   - find the in-scope (i.e. both declared and 'inherited'
declarations)NamespaceDeclarations of a given Element

- Magic that shuffles conflicting or redundant namespace declarations when
Elements are moved within or between Documents. This could end up being
somewhat slow. I'd say make it 'deferrable', i.e. allow (optionally?) NS
declarations to be 'out of sync' after a move until something like
Document.notmalizeNSDeclarations() is called. 


If this covers the needs of NS handling (a big if, granted, but if it
doesn't I'm sure we'll hear about it), I don't think it actually needs
global static data anywhere. 

-pvg

From jteam at knowledgeview.co.uk  Thu Sep 28 04:12:08 2000
From: jteam at knowledgeview.co.uk (Maaziar Sadr)
Date: Fri Aug  6 17:05:03 2004
Subject: [jdom-interest] Bypassing Fetching DTD on JDom
Message-ID: <39D32788.B0C9B51B@knowledgeview.co.uk>

Dear all,
I have a problem regarding parsing an xml file in JDOM api, I appreciate
if
anyone knows a workaround that can help me.
If I have an xml file that contains a DOCTYPE tag in it, and that tag
points
to a URL that is unavailable (for any reason). The DOMBuilder will take
quite sometime trying to fetch that URL.

Is there anyway to force the DOMBuilder to bypass fetching the URL that
is
specified in the DOCTYPE tag?

 I tried using "new DOMBuilder(false);" to disable DTD validation but
still the JDOM api
persists on fetching that URL.

Any help is really appreciated.
Thank you very much.

Best Regards,
Maaziar



From lgonzalez at gltg.com  Thu Sep 28 07:10:20 2000
From: lgonzalez at gltg.com (Lorenzo Gonzalez)
Date: Fri Aug  6 17:05:03 2004
Subject: [jdom-interest] xml:lang Attribute problem
In-Reply-To: <39E4725D.903F0F5F@mn.uswest.net>
Message-ID: <NEBBKKANJMOJEGGFDDCJKEABCBAA.lgonzalez@gltg.com>

Is the following line verbatim from your code?  Take another look at it...

t_xml.append("</Foo");

- Lorenzo


-----Original Message-----
From: jdom-interest-admin@jdom.org
[mailto:jdom-interest-admin@jdom.org]On Behalf Of Perry Hoekstra
Sent: Wednesday, October 11, 2000 8:00 AM
To: jdom-interest@jdom.org
Subject: [jdom-interest] xml:lang Attribute problem


Greet the sun all:

I don't if this is how I implemented it or a bug but when I execute the
following code:

StringBuffer t_xml = new StringBuffer("<?xml version = \"1.0\"?>");

t_xml.append("<Foo xml:lang=\"en-US\">  ");
t_xml.append("</Foo");

org.jdom.input.SAXBuilder t_saxBuilder = new
org.jdom.input.SAXBuilder("org.apache.xerces.parsers.SAXParser");

org.jdom.Document t_jdomDocument = t_saxBuilder.build(new
java.io.StringReader(t_xml.toString()));

I receive the following exception:

org.jdom.JDOMException: The name "" is not legal for JDOM/XML
namespaces: Namespace URIs must be non-null and non-empty Strings..)

Now, looking at page 297 of the XML Bible, it states that xml:lang is a
valid attribute.  I refresh my code with a fresh extract through CVS
this morning. Ideas on what I am doing wrong?

--
Perry Hoekstra
E-Commerce Architect
Talent Software Services
dutchman@mn.uswest.net
_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com


From philip.nelson at omniresources.com  Thu Sep 28 05:33:14 2000
From: philip.nelson at omniresources.com (philip.nelson@omniresources.com)
Date: Fri Aug  6 17:05:03 2004
Subject: [jdom-interest] xml:lang Attribute problem
Message-ID: <DF5018B3C986D11196FF0060089A903C2BFECF@gbdev.omniresource.com>

> I receive the following exception:
> 
> org.jdom.JDOMException: The name "" is not legal for JDOM/XML
> namespaces: Namespace URIs must be non-null and non-empty Strings..)

I'm pretty sure this is fixed now.  The b4 version is now very old and b5
will be released very soon.  Of course you could do what most of us do and
get the latest from CVS ;)

From philip.nelson at omniresources.com  Thu Sep 28 05:37:36 2000
From: philip.nelson at omniresources.com (philip.nelson@omniresources.com)
Date: Fri Aug  6 17:05:03 2004
Subject: [jdom-interest] Bypassing Fetching DTD on JDom
Message-ID: <DF5018B3C986D11196FF0060089A903C2BFED0@gbdev.omniresource.com>

>  I tried using "new DOMBuilder(false);" to disable DTD validation but
> still the JDOM api
> persists on fetching that URL.
> 

hmmm... I don't recall that JDOM does anything at all with SYSTEM id's .
Have you tried it with SAXBuilder?  SAXBuilder gets much more attention
because it's faster and less memory intensive.  If I get a chance I'll take
a look at it tonight because I was just writing tests for the DocType class.

From philip.nelson at omniresources.com  Thu Sep 28 06:39:53 2000
From: philip.nelson at omniresources.com (philip.nelson@omniresources.com)
Date: Fri Aug  6 17:05:03 2004
Subject: [jdom-interest] xml:lang Attribute problem
Message-ID: <DF5018B3C986D11196FF0060089A903C2BFED3@gbdev.omniresource.com>

You are right, there is a bug.  I have tracked it down as far as the
Attribute constructor which doesn't use the bug fix Jason put in.  I am at
work so I can't fix it now but it shouldn't be to difficult.  I will also
add tests for all the constructors at Attribute for xml:lang since that is
allowable.



public Attribute(String name, String prefix, String uri, String value) {
	this(name, value, Namespace.getNamespace(prefix, uri));
}
called from ...

SAXHandler.startElement
	<snip>

} else {
	element.addAttribute(
		new Attribute(name,
			  prefix,
			  getNamespaceURI(prefix),
			  atts.getValue(i)));
			}

From jteam at knowledgeview.co.uk  Thu Sep 28 07:00:53 2000
From: jteam at knowledgeview.co.uk (Maaziar Sadr)
Date: Fri Aug  6 17:05:03 2004
Subject: [jdom-interest] Bypassing Fetching DTD on JDom
References: <DF5018B3C986D11196FF0060089A903C2BFED2@gbdev.omniresource.com>
Message-ID: <39D34F15.59731965@knowledgeview.co.uk>

Sorry I tought that SAX in Jdom is just like jaxpi and is event based.
Anyhow I used SAXBuilder instead of DOMBuilder but my problem is still exists
and
SAXBuilder spend a ling time to fetching DTD like DOMBuilder.

philip.nelson@omniresources.com wrote:

> > Hi philip,
> > Thank you for your responce.
> > Since I need a random access SAX is not my option.
> > take care,
> > Maaziar
> >
>
> Assuming you will use JDOM for that random access, DOMBuilder doesn't help
> you any more than SAXBuilder.  They both do the same thing, they parse and
> they exit.  The main reason for using DOMBuilder is to integrate with other
> tools that may expose a DOM document.


From brett.mclaughlin at lutris.com  Thu Sep 28 07:30:40 2000
From: brett.mclaughlin at lutris.com (Brett McLaughlin)
Date: Fri Aug  6 17:05:03 2004
Subject: [jdom-interest] xml:lang Attribute problem
References: <DF5018B3C986D11196FF0060089A903C2BFED3@gbdev.omniresource.com>
Message-ID: <39D35610.6E09F09A@lutris.com>

Are you sure? The latest version from CVS:

    public Attribute(String name, String value, Namespace namespace) {
        String reason;
        if ((reason = Verifier.checkAttributeName(name)) != null) {
            throw new IllegalNameException(name, "attribute", reason);
        }

        if (namespace == null) {
            namespace = Namespace.NO_NAMESPACE;
        }

        this.name = name;
        setValue(value);
        this.namespace = namespace;
    }

which is called from the otehr constructors. And checkAttributeName:

    public static final String checkAttributeName(String name) {
        // Check basic XML name rules first
        String reason;
        if ((reason = checkXMLName(name)) != null) {
            return reason;
        }

        // Allow xml:space and xml:lang as special cases
        if (name.equals("xml:space") ||
            name.equals("xml:lang")) {
            return null;
        }

        // Otherwise, no colons are allowed,
        // since attributes handle this internally
        if (name.indexOf(":") != -1) {
            return "Attribute names cannot contain colons";
        }

        // If we got here, everything is OK
        return null;
    }

Which would seem to do the right thing. Is this the latest CVS?

Trying to track this down...

-Brett

philip.nelson@omniresources.com wrote:
> 
> You are right, there is a bug.  I have tracked it down as far as the
> Attribute constructor which doesn't use the bug fix Jason put in.  I am at
> work so I can't fix it now but it shouldn't be to difficult.  I will also
> add tests for all the constructors at Attribute for xml:lang since that is
> allowable.
> 
> public Attribute(String name, String prefix, String uri, String value) {
>         this(name, value, Namespace.getNamespace(prefix, uri));
> }
> called from ...
> 
> SAXHandler.startElement
>         <snip>
> 
> } else {
>         element.addAttribute(
>                 new Attribute(name,
>                           prefix,
>                           getNamespaceURI(prefix),
>                           atts.getValue(i)));
>                         }
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org

From brett.mclaughlin at lutris.com  Thu Sep 28 07:35:10 2000
From: brett.mclaughlin at lutris.com (Brett McLaughlin)
Date: Fri Aug  6 17:05:03 2004
Subject: [jdom-interest] Bug fix in SAXBuilder and DOMBuilder
Message-ID: <39D3571E.7ACCB567@lutris.com>

All-

  Just made a little bugfix to SAXBuilder and DOMBuilder - now it checks
for "xmlns:" instead of just "xmlns" on attribute names. This is of
course from a long time ago, to avoid problems when some goofy user uses
xmlnsfoo as an attribute name ;-)

-Brett

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org

From philip.nelson at omniresources.com  Thu Sep 28 07:28:50 2000
From: philip.nelson at omniresources.com (philip.nelson@omniresources.com)
Date: Fri Aug  6 17:05:03 2004
Subject: [jdom-interest] xml:lang Attribute problem
Message-ID: <DF5018B3C986D11196FF0060089A903C2BFED6@gbdev.omniresource.com>

I have the version i got on 9/25. The 4 parameter constructor doesn't call
checkAttribute name.  The problem seems to be that in this scenario, the
prefix and name have already be separated.

> -----Original Message-----
> From: Brett McLaughlin [mailto:brett.mclaughlin@lutris.com]
> Sent: Thursday, September 28, 2000 9:31 AM
> To: philip.nelson@omniresources.com
> Cc: dutchman@uswest.net; jdom-interest@jdom.org
> Subject: Re: [jdom-interest] xml:lang Attribute problem
> 
> 
> Are you sure? The latest version from CVS:
> 
>     public Attribute(String name, String value, Namespace namespace) {
>         String reason;
>         if ((reason = Verifier.checkAttributeName(name)) != null) {
>             throw new IllegalNameException(name, "attribute", reason);
>         }
> 
>         if (namespace == null) {
>             namespace = Namespace.NO_NAMESPACE;
>         }
> 
>         this.name = name;
>         setValue(value);
>         this.namespace = namespace;
>     }
> 
> which is called from the otehr constructors. And checkAttributeName:
> 
>     public static final String checkAttributeName(String name) {
>         // Check basic XML name rules first
>         String reason;
>         if ((reason = checkXMLName(name)) != null) {
>             return reason;
>         }
> 
>         // Allow xml:space and xml:lang as special cases
>         if (name.equals("xml:space") ||
>             name.equals("xml:lang")) {
>             return null;
>         }
> 
>         // Otherwise, no colons are allowed,
>         // since attributes handle this internally
>         if (name.indexOf(":") != -1) {
>             return "Attribute names cannot contain colons";
>         }
> 
>         // If we got here, everything is OK
>         return null;
>     }
> 
> Which would seem to do the right thing. Is this the latest CVS?
> 
> Trying to track this down...
> 
> -Brett
> 
> philip.nelson@omniresources.com wrote:
> > 
> > You are right, there is a bug.  I have tracked it down as far as the
> > Attribute constructor which doesn't use the bug fix Jason 
> put in.  I am at
> > work so I can't fix it now but it shouldn't be to 
> difficult.  I will also
> > add tests for all the constructors at Attribute for 
> xml:lang since that is
> > allowable.
> > 
> > public Attribute(String name, String prefix, String uri, 
> String value) {
> >         this(name, value, Namespace.getNamespace(prefix, uri));
> > }
> > called from ...
> > 
> > SAXHandler.startElement
> >         <snip>
> > 
> > } else {
> >         element.addAttribute(
> >                 new Attribute(name,
> >                           prefix,
> >                           getNamespaceURI(prefix),
> >                           atts.getValue(i)));
> >                         }
> > _______________________________________________
> > To control your jdom-interest membership:
> > 
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org

From brett.mclaughlin at lutris.com  Thu Sep 28 08:51:20 2000
From: brett.mclaughlin at lutris.com (Brett McLaughlin)
Date: Fri Aug  6 17:05:03 2004
Subject: [jdom-interest] xml:lang Attribute problem
References: <DF5018B3C986D11196FF0060089A903C2BFED6@gbdev.omniresource.com>
Message-ID: <39D368F8.2F64190A@lutris.com>

OK, I see. What is the exact Exception thrown? I'm tracking it down.

Thanks,
Brett

philip.nelson@omniresources.com wrote:
> 
> I have the version i got on 9/25. The 4 parameter constructor doesn't call
> checkAttribute name.  The problem seems to be that in this scenario, the
> prefix and name have already be separated.
> 
> > -----Original Message-----
> > From: Brett McLaughlin [mailto:brett.mclaughlin@lutris.com]
> > Sent: Thursday, September 28, 2000 9:31 AM
> > To: philip.nelson@omniresources.com
> > Cc: dutchman@uswest.net; jdom-interest@jdom.org
> > Subject: Re: [jdom-interest] xml:lang Attribute problem
> >
> >
> > Are you sure? The latest version from CVS:
> >
> >     public Attribute(String name, String value, Namespace namespace) {
> >         String reason;
> >         if ((reason = Verifier.checkAttributeName(name)) != null) {
> >             throw new IllegalNameException(name, "attribute", reason);
> >         }
> >
> >         if (namespace == null) {
> >             namespace = Namespace.NO_NAMESPACE;
> >         }
> >
> >         this.name = name;
> >         setValue(value);
> >         this.namespace = namespace;
> >     }
> >
> > which is called from the otehr constructors. And checkAttributeName:
> >
> >     public static final String checkAttributeName(String name) {
> >         // Check basic XML name rules first
> >         String reason;
> >         if ((reason = checkXMLName(name)) != null) {
> >             return reason;
> >         }
> >
> >         // Allow xml:space and xml:lang as special cases
> >         if (name.equals("xml:space") ||
> >             name.equals("xml:lang")) {
> >             return null;
> >         }
> >
> >         // Otherwise, no colons are allowed,
> >         // since attributes handle this internally
> >         if (name.indexOf(":") != -1) {
> >             return "Attribute names cannot contain colons";
> >         }
> >
> >         // If we got here, everything is OK
> >         return null;
> >     }
> >
> > Which would seem to do the right thing. Is this the latest CVS?
> >
> > Trying to track this down...
> >
> > -Brett
> >
> > philip.nelson@omniresources.com wrote:
> > >
> > > You are right, there is a bug.  I have tracked it down as far as the
> > > Attribute constructor which doesn't use the bug fix Jason
> > put in.  I am at
> > > work so I can't fix it now but it shouldn't be to
> > difficult.  I will also
> > > add tests for all the constructors at Attribute for
> > xml:lang since that is
> > > allowable.
> > >
> > > public Attribute(String name, String prefix, String uri,
> > String value) {
> > >         this(name, value, Namespace.getNamespace(prefix, uri));
> > > }
> > > called from ...
> > >
> > > SAXHandler.startElement
> > >         <snip>
> > >
> > > } else {
> > >         element.addAttribute(
> > >                 new Attribute(name,
> > >                           prefix,
> > >                           getNamespaceURI(prefix),
> > >                           atts.getValue(i)));
> > >                         }
> > > _______________________________________________
> > > To control your jdom-interest membership:
> > >
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
> t.com
> 
> --
> Brett McLaughlin, Enhydra Strategist
> Lutris Technologies, Inc.
> 1200 Pacific Avenue, Suite 300
> Santa Cruz, CA 95060 USA
> http://www.lutris.com
> http://www.enhydra.org

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org

From brett.mclaughlin at lutris.com  Thu Sep 28 09:15:26 2000
From: brett.mclaughlin at lutris.com (Brett McLaughlin)
Date: Fri Aug  6 17:05:03 2004
Subject: [jdom-interest] xml:lang Attribute problem
References: <DF5018B3C986D11196FF0060089A903C2BFED6@gbdev.omniresource.com> <39D368F8.2F64190A@lutris.com> <39D3699D.F109223D@mn.uswest.net>
Message-ID: <39D36E9E.E699A12E@lutris.com>


Perry Hoekstra wrote:
> 
> Brett McLaughlin wrote:
> >
> > OK, I see. What is the exact Exception thrown? I'm tracking it down.
> >
> > Thanks,
> > Brett
> 
> org.jdom.JDOMException: The name "" is not legal for JDOM/XML
> namespaces: Namespace URIs must be non-null and non-empty Strings


OK. Finally - I think I got it. Can you check out the code in CVS and
try it, and let me know?

Thanks,
Brett

> 
> --
> Perry Hoekstra
> E-Commerce Architect
> Talent Software Services
> dutchman@mn.uswest.net

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org

From dutchman at uswest.net  Thu Sep 28 08:54:05 2000
From: dutchman at uswest.net (Perry Hoekstra)
Date: Fri Aug  6 17:05:03 2004
Subject: [jdom-interest] xml:lang Attribute problem
References: <DF5018B3C986D11196FF0060089A903C2BFED6@gbdev.omniresource.com> <39D368F8.2F64190A@lutris.com>
Message-ID: <39D3699D.F109223D@mn.uswest.net>


Brett McLaughlin wrote:
> 
> OK, I see. What is the exact Exception thrown? I'm tracking it down.
> 
> Thanks,
> Brett

org.jdom.JDOMException: The name "" is not legal for JDOM/XML
namespaces: Namespace URIs must be non-null and non-empty Strings

-- 
Perry Hoekstra
E-Commerce Architect
Talent Software Services
dutchman@mn.uswest.net

From dutchman at uswest.net  Thu Sep 28 05:48:00 2000
From: dutchman at uswest.net (Perry Hoekstra)
Date: Fri Aug  6 17:05:03 2004
Subject: [jdom-interest] xml:lang Attribute problem
References: <DF5018B3C986D11196FF0060089A903C2BFECF@gbdev.omniresource.com>
Message-ID: <39D33E00.B96211BE@mn.uswest.net>

philip.nelson@omniresources.com wrote:
> 
> > I receive the following exception:
> >
> > org.jdom.JDOMException: The name "" is not legal for JDOM/XML
> > namespaces: Namespace URIs must be non-null and non-empty Strings..)
> 
> I'm pretty sure this is fixed now.  The b4 version is now very old and b5
> will be released very soon.  Of course you could do what most of us do and
> get the latest from CVS ;)

I did a CVS refresh before posting to list to see if the problem had
been fixed using the following CVS command:

cvs -d :pserver:anonymous@cvs.jdom.org:/home/cvspublic co jdom

Do I need to point to a different branch?


-- 
Perry Hoekstra
E-Commerce Architect
Talent Software Services
dutchman@mn.uswest.net

How would the child that you were view the person you've become
- Anonymous

From dutchman at uswest.net  Thu Sep 28 10:25:10 2000
From: dutchman at uswest.net (Perry Hoekstra)
Date: Fri Aug  6 17:05:03 2004
Subject: [jdom-interest] xml:lang Attribute problem
References: <DF5018B3C986D11196FF0060089A903C2BFED6@gbdev.omniresource.com> <39D368F8.2F64190A@lutris.com> <39D3699D.F109223D@mn.uswest.net> <39D36E9E.E699A12E@lutris.com>
Message-ID: <39D37EF6.C98EB452@mn.uswest.net>


Brett McLaughlin wrote:
> 
> OK. Finally - I think I got it. Can you check out the code in CVS and
> try it, and let me know?

Yes, the test works.  However, whole bunches of code now break because
Element.getChild(*) no longer throws NoSuchElementException.  Can you
given the change so that I can integrate it with my copy of Beta4?  My
timeline does not allow for redoing a lot of code.

-- 
Perry Hoekstra
E-Commerce Architect
Talent Software Services
dutchman@mn.uswest.net

From brett.mclaughlin at lutris.com  Thu Sep 28 10:39:41 2000
From: brett.mclaughlin at lutris.com (Brett McLaughlin)
Date: Fri Aug  6 17:05:03 2004
Subject: [jdom-interest] xml:lang Attribute problem
References: <DF5018B3C986D11196FF0060089A903C2BFED6@gbdev.omniresource.com> <39D368F8.2F64190A@lutris.com> <39D3699D.F109223D@mn.uswest.net> <39D36E9E.E699A12E@lutris.com> <39D37EF6.C98EB452@mn.uswest.net>
Message-ID: <39D3825D.3AE173E5@lutris.com>


Perry Hoekstra wrote:
> 
> Brett McLaughlin wrote:
> >
> > OK. Finally - I think I got it. Can you check out the code in CVS and
> > try it, and let me know?
> 
> Yes, the test works.  However, whole bunches of code now break because
> Element.getChild(*) no longer throws NoSuchElementException.  Can you
> given the change so that I can integrate it with my copy of Beta4?  My
> timeline does not allow for redoing a lot of code.

Unfortunately, no. JDOM in beta form is just not 100% guaranteed. We
certainly hope you are willing to make the changes - there are so many
fixes in beta 5 that you would more than pay the price using beta 4 over
again as opposed to changing your code.

Sorry about that ;-)

-Brett

> 
> --
> Perry Hoekstra
> E-Commerce Architect
> Talent Software Services
> dutchman@mn.uswest.net

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org

From jhunter at collab.net  Thu Sep 28 11:22:14 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:05:03 2004
Subject: [jdom-interest] xml:lang Attribute problem
References: <DF5018B3C986D11196FF0060089A903C2BFED6@gbdev.omniresource.com> <39D368F8.2F64190A@lutris.com> <39D3699D.F109223D@mn.uswest.net> <39D36E9E.E699A12E@lutris.com> <39D37EF6.C98EB452@mn.uswest.net> <39D3825D.3AE173E5@lutris.com>
Message-ID: <39D38C56.543D953A@collab.net>

> > Can you given the change so that I can integrate it with my 
> > copy of Beta4?  My
> > timeline does not allow for redoing a lot of code.

You can see all diffs at http://cvs.jdom.org.  But like Brett said,
there's been so many changes since beta4 (esp regarding namespaces) that
patching beta4 for an individual fix is a "fend for yourself" activity. 
:-)

-jh-

From tsasala at hifusion.com  Thu Sep 28 12:42:00 2000
From: tsasala at hifusion.com (tsasala@hifusion.com)
Date: Fri Aug  6 17:05:03 2004
Subject: [jdom-interest] Build problem
Message-ID: <39D39F08.AD1FFC01@hifusion.com>

	I just want to let everyone know that I was unable to 
build the JDOM jar under Linux using JDK 1.2.2 RC4.  Now that
I have upgraded to FCS, everything works find.  Must have
something to do with the Xerces or Ant jar, since those
are the only things that have changed from when I could
compile and couldn't compile.

 	JDK 1.2.2 FCS
	Kernel 2.2.14

	-Tom

-- 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ Thomas M. Sasala, Senior Developer             tsasala@hifusion.com     + 
+ HiFusion, Inc.                                 (W) 703.848.4441         +
+ 8180 Greensboro Dr, #500                       (F) 703.848.4420         +
+ McLean, VA  22102                                                       + 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

From Vamshi.Reddy at whn.com  Thu Sep 28 19:26:29 2000
From: Vamshi.Reddy at whn.com (Vamshi Reddy)
Date: Fri Aug  6 17:05:03 2004
Subject: [jdom-interest] bug in Element()  ?
Message-ID: <213B28F4301DD411A81300508B0CCCDA0810F0@WHNEXG01.hq.whn.com>

How is it possible to add a child element at a given index?

Element.addChild(Element) inserts the element at the end of the list. There
is no method to specify the index.
To do this do we have to first create a new list and add the element at the
required index and continue to add the children? There must be a better way.
DOM parsers usually let you insert elements at any point in the list. 

(Element.addChild(index, Element) -- index to insertAt?)

Is it possible to use the List.add() or with listIterator on a sync'd List
without an IllegalAddException?

org.w3c.dom has these operation in Node and ProcessingInstruction extends
Node. Shouldn't JDOM have something similiar at least? Is there a way to
manipulate the element through PI?

About setName(): An alternative given in the new docs is the setParent() but
you still have to first get the child of the old (parent) element, make a
new (parent) element and then setParent(). Still cannot think of a simple
reason why it was necessary to remove it. It does not make it any easier.

Thanks in advance,

Vamshi

-----Original Message-----
From: jdom-interest-admin@jdom.org
[mailto:jdom-interest-admin@jdom.org]On Behalf Of
jdom-interest-request@jdom.org
Sent: Wednesday, September 27, 2000 3:38 PM
To: jdom-interest@jdom.org
Subject: jdom-interest digest, Vol 1 #259 - 26 msgs


Send jdom-interest mailing list submissions to
	jdom-interest@jdom.org

To subscribe or unsubscribe via the World Wide Web, visit
	http://lists.denveronline.net/mailman/listinfo/jdom-interest
or, via email, send a message with subject or body 'help' to
	jdom-interest-request@jdom.org

You can reach the person managing the list at
	jdom-interest-admin@jdom.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of jdom-interest digest..."


Today's Topics:

  1. Re: Beta 5:  SaxBuilder constructor crashes Hunter &
 McLaughlin's code (Jason Hunter)
  2. Re: Beta5 candidate (Jason Hunter)
  3. (no subject) (Peter V. Gadjokov)
  4. Re: (Jason Hunter)
  5. RE: Beta5 candidate (Peter V. Gadjokov)
  6. Re: Beta5 candidate (Jason Hunter)
  7. RE: Beta5 candidate (Peter V. Gadjokov)
  8. Re: Re: static data needs to be thread data for
 multithreaded applications (Peter V. Gadjokov)
  9. Iterator.remove() is calling a non-overloaded method to remove children
from an element. (Travers Waker)
  10. Re: Beta5 candidate (Michael Engelhart)
  11. RE: Re: static data needs to be thread data for
 multithreaded applications (philip.nelson@omniresources.com)
  12. No access to namespaces? (alan.quinton@autodesk.com)
  13. RE: Iterator.remove() is calling a non-overloaded
 method to remove children from an element. (Peter V. Gadjokov)
  14. Re: Re: static data needs to be thread data for
 multithreaded applications (Jason Hunter)
  15. Re: Iterator.remove() is calling a non-overloadedmethod
 to remove children from an element. (Jason Hunter)
  16. RE: Iterator.remove() is calling a non-overloaded
 method  to remove children from an element. (Peter V. Gadjokov)
  17. RE: Re: static data needs to be thread data for
 multithreaded applications (Peter V. Gadjokov)
  18. xml:lang Attribute problem (Perry Hoekstra)

--__--__--

Message: 1
Date: Tue, 26 Sep 2000 23:55:36 -0700
From: Jason Hunter <jhunter@collab.net>
To: "Michael F. Baker" <mfbaker@home.com>
CC: jdom-interest@jdom.org
Subject: Re: [jdom-interest] Beta 5:  SaxBuilder constructor crashes Hunter
&
McLaughlin's code

> I just downloaded JDOM beta 5, and the SaxBuilder constructor 
> line below crashes the application.  Anyone have any ideas?
> Thanks!
> - Mike

What *exactly* does "crashes the app" mean?

-jh-

--__--__--

Message: 2
Date: Wed, 27 Sep 2000 00:02:15 -0700
From: Jason Hunter <jhunter@collab.net>
To: "Peter V. Gadjokov" <pvg@c-c-s.com>
CC: jdom-interest@jdom.org
Subject: Re: [jdom-interest] Beta5 candidate

> Could I get the serialization changes in? If so, how? I haven't 
> had time to write a test-suite but it does work, I get the same 
> trees out that I serialize.

Well, I wouldn't want to hold up beta5 for those changes.  We're simply
too desperate to have a new milestone.  On the other hand, getting them
into beta5 gives us an opportunity to test how well we migrate to
beta6.  Exactly how far along are you?  How substantial is the patch?

-jh-

--__--__--

Message: 3
From: "Peter V. Gadjokov" <pvg@c-c-s.com>
To: "'jhunter@collab.net'" <jhunter@collab.net>
Cc: "'jdom-interest@jdom.org'" <jdom-interest@jdom.org>
Date: Wed, 27 Sep 2000 00:22:03 -0700
charset="iso-8859-1"
Subject: [jdom-interest] (no subject)

>Well, I wouldn't want to hold up beta5 for those changes.  We're simply
>too desperate to have a new milestone.  On the other hand, getting them
>into beta5 gives us an opportunity to test how well we migrate to
>beta6.  

Yep, I'd like to see it tested but no, I do not want to hold up a release.
As an aside, perhaps it's worth considering having somewhat more frequent
beta releases - the 'get it from cvs' is a very frequent response to bug
reports. 

>Exactly how far along are you?  How substantial is the patch?

I'm done, I've been sitting on it for a bit (since I sent out those perf.
numbers). The patch is small, writeObject and readObject methods are added
to all stored classes. I've tweaked Namespace a bit for better performance
but I'll take those changes out for the time being, the whole class is
likely to be rewritten by someone soon anyway. 
The only other changes are a SerializationUtils class with a couple of
static methods to reuse the custom serialization of Namespace and List. Oh
and I've abstracted the lazy instantiation of the content and attribute
lists in Element to two private methods since the constant repetition of new
LinkedList() all over Element somewhat defeats the purpose of declaring the
ivar List. That change is also fair game for killing if it seems
inappropriate. That's it. Should I just mail c-diffs to the list? 

-pvg

--__--__--

Message: 4
Date: Wed, 27 Sep 2000 00:45:55 -0700
From: Jason Hunter <jhunter@collab.net>
To: "Peter V. Gadjokov" <pvg@c-c-s.com>
CC: "'jdom-interest@jdom.org'" <jdom-interest@jdom.org>
Subject: [jdom-interest] Re:

> As an aside, perhaps it's worth considering having somewhat 
> more frequent beta releases - the 'get it from cvs' is a very 
> frequent response to bug reports.

Exactly!  That's why I'm not holding up this one any.

> Should I just mail c-diffs to the list?

Yep.  Make sure the utils class is package protected.  (Even at that
it's unfortunate we'd need another class, even a support class, for
people to see in the package.  Any way to do it elegantly without the
extra class?)

-jh-

--__--__--

Message: 5
From: "Peter V. Gadjokov" <pvg@c-c-s.com>
To: "'jhunter@collab.net'" <jhunter@collab.net>
Cc: "'jdom-interest@jdom.org'" <jdom-interest@jdom.org>
Subject: RE: [jdom-interest] Beta5 candidate
Date: Wed, 27 Sep 2000 01:17:20 -0700
charset="iso-8859-1"


>Yep.  Make sure the utils class is package protected.  (Even at that
>it's unfortunate we'd need another class, even a support class, for
>people to see in the package.  Any way to do it elegantly without the
>extra class?)

I've put it in a org.jdom.util package but that's easy to change to org.jdom
and package protect it if that goes down better. It's not really a class,
just a couple of global functions. Their functionality can be explicitly cut
and pasted in the 3-5 places in which it is used. That's not 'elegant' in my
book but I'm not religious about it, I can make that change too, it will
just be a little more annoying to maintain in the future. 

Here's what it looks like - 

public class SerializationUtils
{
    public static void writeList(List list, ObjectOutputStream out)
        throws IOException
    [...] 
    public static List readList(ObjectInputStream in)
        throws IOException, ClassNotFoundException
    [...]	
    public static void writeNamespace(Namespace ns, ObjectOutputStream out)
        throws IOException
    [...] 
    public static Namespace readNamespace(ObjectInputStream in)
        throws IOException, ClassNotFoundException
    [...]
}

And it gets called in places like this - Element.writeObject - 

    private void writeObject(ObjectOutputStream out) throws IOException {
        
        out.writeInt(JDOM_ELEMENT_SVER);
        out.writeObject(name);
        SerializationUtils.writeList(attributes, out);
        SerializationUtils.writeList(content, out);
        SerializationUtils.writeNamespace(namespace, out);
    }

I just grepped my tree, there are three call pairs from two classes to
write/read list and two call pairs from two classes to write/read namespace.
Let me know which way you'd prefer to see this go, I'll wrap it up and spew
to the list tonight (or shortly after I hear from you)

-pvg

--__--__--

Message: 6
Date: Wed, 27 Sep 2000 01:40:09 -0700
From: Jason Hunter <jhunter@collab.net>
To: "Peter V. Gadjokov" <pvg@c-c-s.com>
CC: "'jdom-interest@jdom.org'" <jdom-interest@jdom.org>
Subject: Re: [jdom-interest] Beta5 candidate

>     public static void writeList(List list, ObjectOutputStream out)
>         throws IOException
>     [...]
>     public static List readList(ObjectInputStream in)
>         throws IOException, ClassNotFoundException
>     [...]

Well, this could go in PartialList.

>     public static void writeNamespace(Namespace ns, ObjectOutputStream
out)
>         throws IOException
>     [...]
>     public static Namespace readNamespace(ObjectInputStream in)
>         throws IOException, ClassNotFoundException
>     [...]
> }

And this probably really should go in Namespace -- let the class take
care of its own serialization.

Using PartialList that way is probably just slightly less elegant for
us, but easier on the new JDOM user, and it's evened out by having
Namespace do its own internal management which I like in general
anyway.  At least that's my 1:40am thinking.

-jh-

--__--__--

Message: 7
From: "Peter V. Gadjokov" <pvg@c-c-s.com>
To: "'jhunter@collab.net'" <jhunter@collab.net>
Cc: "'jdom-interest@jdom.org'" <jdom-interest@jdom.org>
Subject: RE: [jdom-interest] Beta5 candidate
Date: Wed, 27 Sep 2000 02:17:55 -0700
charset="iso-8859-1"

>Well, this could go in PartialList.

It could, it doesn't quite belong there since it stores any kind of List.
I'm not 100% sure but I think PartialList messes with the contract of the
List interface in ways that if you actually used this method to store a
PartialList, you won't get the exact same thing back when you read it, in
certain cases.  But as I said, I'm not religious about it, it's a workable
solution, I'll go with it unless you've had a better 2:15am insight in the
interim. 

>And this probably really should go in Namespace -- let the class take
>care of its own serialization.

Yeah, that's a better way. I should have thought of it but I already had the
utils class when I added that method. The Namespace thing can be taken care
of by standard means (readResolve/writeReplace/ObjectInputValidation
trickery) but I don't think that works on 1.1. Package protected statics in
Namespace are practically as good and more compatible. I think we have
consensus then. 

I would be against holding up a b5 release to sort out the get Child/Element
issues. I think the API is likely to be affected by the next rev of
namespace handling. No matter what design we go with, it will have to be
able to represent namespace declarations, distinguish between namespace name
[info set term] and  namespace decal. and perhaps even be able to do
in-scope tests. Such changes seem significant enough to likely affect our
views and the practical details of the traversal methods.

I'm putting with something else right now (a little JDOM-based utility to
make graphviz[http://www.research.att.com/sw/tools/graphviz/]
pretty-pictures of XML docs, I'll make it available if anyone else has a use
for it) but I'll make the serialization changes sometime tonight and email
them out. Thanks for the feedback. 

-pvg


--__--__--

Message: 8
From: "Peter V. Gadjokov" <pvg@c-c-s.com>
To: "'jhunter@collab.net'" <jhunter@collab.net>
Cc: "'jdom-interest@jdom.org'" <jdom-interest@jdom.org>
Subject:  Re: [jdom-interest] Re: static data needs to be thread data for
multithreaded applications
Date: Wed, 27 Sep 2000 02:53:46 -0700
charset="iso-8859-1"

>Yep.  Weak references would come to the rescue.  I added a note in the
>code to mark this as a future possibility.  (I'm postponing action
>because it's potentially a lot of code and testing in an area that's
>been changing, and because weak refs don't work in JDK 1.1.)

My use of JDOM is also in server-world and I'd prefer to see a slightly
different direction - JDOM is a utility API so I think it should, as far as
possible, avoid making resource-management decisions for the API user and
when it does, it should provide hooks for as much control as feasible. In
the case of namespaces - assuming JDOM can one day tell between a namespace
name and a namespace declaration - Namespace declarations (or rather, their
prefix mappings) will probably be bound to a particular document so the
static data issue goes away there. If there is a big howl for memory sharing
between instances of docs with identical prefix mappings, the management of
that stuff can be opened up with an interface and you could optionally set a
prefix mapping manager delegate on docs. As to namespace names, I can't see
a good reason to keep these as global data either. There is no reason to go
through hoops to steal some CPU and save me some memory so I can do an
identity (==) comparison between namespace names. The comparison can be
optimized so it rarely has to do a full string comparison (and the URI
strings themselves can be interned for ==). For the memory-conscious, a
NamespaceName.intern() can be added. 

Short'n'sweet - the static-data/sync problem is partially exacerbated by the
lack of separation between namespace name and namespace declaration and the
centralized storage of things that may not need centralized management under
a better model. Weak references alone are not a good option for serious
server-side use -I might (well, I do) want better control than that (say, a
configurable, explicitly bounded LRU cache that is based on weak
references). 

-pvg

--__--__--

Message: 9
From: "Travers Waker" <traversw@innoforge.co.za>
To: <jdom-interest@jdom.org>
Date: Wed, 27 Sep 2000 12:56:01 +0200
charset="iso-8859-1"
Subject: [jdom-interest] Iterator.remove() is calling a non-overloaded
method to remove children from an element.

Hi.

Calling Element.getChildren() returns a "live" list that modifies the
original XML document tree.  Whatever list JDOM returns obiviously has
overloaded methods for List.remove(Element name) to unset the pointer this
elements parent Element and perform other similar JDOM-specific tasks.

However, when one get's an Iterator for this List (i.e.
Element.getChildren().iterator()), the Iterator.remove() method calls a
method of the underlying list that is not overloaded to update the internal
fields of Element (e.g Element.parent).  The following code illustrates the
problem: (The code just moves a child element from parent1 to parent2).

package tests.jdom;
import java.util.*;
import org.jdom.*;

class JdomListTest2 {

  public static void main(String[] args) throws Exception {

    Element parent1 = new Element("parent1");
    Element parent2 = new Element("parent2");

    parent1.addContent(new Element("child"));

    List list = parent1.getChildren();
    Iterator it = list.iterator();
    Element child = (Element)it.next();
    // list.remove(child);
    it.remove();

    parent2.addContent(child);

  }
}

The error generated is:

org.jdom.IllegalAddException: The element "child" could not be added as a
child of "parent2": The element already has an existing parent "parent1"
 at org.jdom.Element.addContent(Element.java:846)
 at tests.jdom.JdomListTest2.main(JdomListTest2.java:20)
Exception in thread "main"

If I uncomment "list.remove(child)" and comment out "it.remove()",
everything works as expected.  This is not as efficient as using
it.remove(), because list.remove(child) involves searching through the list
again for teh "child" element, even though the Iterator (it) is pointing to
exact location of child already!

Shouldn't be that hard to fix, but it would take a while to get familiar
with the JDOM code and CVS, so I think I'd better let someone who knows what
they're doing add support for Iterator.remove().

Thanks

Travers


--__--__--

Message: 10
Date: Wed, 27 Sep 2000 08:24:12 -0500
Reply-To: mengelhart@earthtrip.com
charset=us-ascii
From: Michael Engelhart <mengelhart@earthtrip.com>
To: jdom-interest@jdom.org, Jason Hunter <jhunter@collab.net>
Subject: Re: [jdom-interest] Beta5 candidate

Has the bug been fixed where attributes that have escaped string values get
unescaped upon parsing the XML document for beta 5?  This has been driving
me insane but it doesn't appear that it has been fixed as of yet.    Anyone
know?

Mike

--__--__--

Message: 11
From: philip.nelson@omniresources.com
To: jdom-interest@jdom.org
Subject: RE: [jdom-interest] Re: static data needs to be thread data for
multithreaded applications
Date: Wed, 27 Sep 2000 13:04:51 -0500
charset="iso-8859-1"



> My use of JDOM is also in server-world and I'd prefer to see 
> a slightly
> different direction - JDOM is a utility API so I think it 
> should, as far as
> possible, avoid making resource-management decisions for the 
> API user and
> when it does, it should provide hooks for as much control as 
> feasible. In
> the case of namespaces - assuming JDOM can one day tell 
> between a namespace
> name and a namespace declaration - Namespace declarations (or 
> rather, their
> prefix mappings) will probably be bound to a particular 
> document so the
> static data issue goes away there.

Are you all thinking about using the getDocument to find locate the home for
the namespaces and or prefix mappings?  At the time NameSpace was written,
there was a lot of discussion about the static hashtables but because nobody
wanted to maintain parent relationships, there was no way to put namespace
information in the Document for any given element.  It seems this has
changed since then.

> Short'n'sweet - the static-data/sync problem is partially 
> exacerbated by the
> lack of separation between namespace name and namespace 
> declaration and the
> centralized storage of things that may not need centralized 
> management under
> a better model. 

I apologize in advance but I don't understand what you mean by "lack of
separation between namespace name and namespace declaration".  I think that
the static variables in Namespace can't work on a server, or at least that
it's more compromises that it's worth.  It does work in what I think would
have to be the more common use case of many similar xml documents processed
by a server app.  My use case is a problem.  I would think that
serialization would be complicated as well.

--__--__--

Message: 12
From: alan.quinton@autodesk.com
To: jdom-interest@jdom.org
Date: Wed, 27 Sep 2000 12:03:27 -0700
charset="iso-8859-1"
Subject: [jdom-interest] No access to namespaces?

Can anyone say why the B4 documentation provides access to the namespace
mappings while the actual code does not? Functions such as
getNamespaceURI(), getNamespaceMappings() are documented, but not
implemented in the jar file, or the code? Were these removed for a reason?

I need to get the URI associated with the prefix "" in the document so that
I can make a proper call to element.getAttribute(), I can't seem to find a
way to get this information...

Thanks in advance,
-Alan

--__--__--

Message: 13
From: "Peter V. Gadjokov" <pvg@c-c-s.com>
To: "'Travers Waker'" <traversw@innoforge.co.za>, jdom-interest@jdom.org
Subject: RE: [jdom-interest] Iterator.remove() is calling a non-overloaded
method to remove children from an element.
Date: Wed, 27 Sep 2000 12:40:03 -0700
charset="iso-8859-1"




>Shouldn't be that hard to fix, but it would take a while to get familiar
>with the JDOM code and CVS, so I think I'd better let someone who knows
what
>they're doing add support for Iterator.remove().

It might be a little harder to fix than it looks, most likely PartialList
will have to provide its own Iterator (or perhaps someone can write a
ListView-type class that does not replicate storage and is not so gory).
PartialList _does_ appear to override all the relevant methods and take care
of setting the parent to null. The trouble is that the ListIterator impl
inside LinkedList (the superclass of PartialList, the ListIterator impl is a
private class it defines) does not actually call LinkedList.remove(Object),
it calls 
LinkedList.remove(Entry)
which is a private method and does all the work. PartialList never gets a
chance to get a method in edgewise. This is a little tricky to see in a
debugger because the private method is inlined in the ListItr
implementation. It's also not completely obvious from a quick glance at the
source since the type declaration of the 'lastReturned' ivar is no longer
visible in one's editor window. Isn't overloading fun?

In any event, the fix is worth thinking about some. It is also an
interesting datapoint in the 'is Element a List' debate - neither the person
who wrote the class nor the people who use JDOM (myself included) ever made
use of the 'live list' functionality enough to notice the issue :)

-pvg



--__--__--

Message: 14
Date: Wed, 27 Sep 2000 13:57:05 -0700
From: Jason Hunter <jhunter@collab.net>
To: philip.nelson@omniresources.com
CC: jdom-interest@jdom.org
Subject: Re: [jdom-interest] Re: static data needs to be thread data for
multithreaded applications

> At the time NameSpace was written,
> there was a lot of discussion about the static hashtables but 
> because nobody wanted to maintain parent relationships, there was 
> no way to put namespace information in the Document for any 
> given element.  It seems this has changed since then.

Elements can still exist unattached to a Document.

-jh-

--__--__--

Message: 15
Date: Wed, 27 Sep 2000 14:07:48 -0700
From: Jason Hunter <jhunter@collab.net>
To: "Peter V. Gadjokov" <pvg@c-c-s.com>
CC: "'Travers Waker'" <traversw@innoforge.co.za>, jdom-interest@jdom.org
Subject: Re: [jdom-interest] Iterator.remove() is calling a
non-overloadedmethod
to remove children from an element.

> It might be a little harder to fix than it looks, most 
> likely PartialList will have to provide its own Iterator 
> (or perhaps someone can write a ListView-type class that does 
. not replicate storage and is not so gory).

Yep.  It's not a trivial fix (thus it's in the TODO.txt file and not
already done in the code) but it's a pretty straightforward fix.  I
suspect you could wrap a PartialListIterator around the ListItr normally
returned, and have it remove the elt from the backing list and then let
ListItr do its normal thing.

-jh-

--__--__--

Message: 16
From: "Peter V. Gadjokov" <pvg@c-c-s.com>
To: "'Jason Hunter'" <jhunter@collab.net>
Cc: "'Travers Waker'" <traversw@innoforge.co.za>, jdom-interest@jdom.org
Subject: RE: [jdom-interest] Iterator.remove() is calling a non-overloaded
method  to remove children from an element.
Date: Wed, 27 Sep 2000 14:28:06 -0700
charset="iso-8859-1"

>I suspect you could wrap a PartialListIterator around the ListItr normally
>returned, and have it remove the elt from the backing list and then let
>ListItr do its normal thing.

What's the difficulty in having a predicated (filtered) sub-list class that
is just a plain wrapper around a List (any List, not just a LinkedList) as
opposed to the strange wrapper'n'subclass beast that PartialList is?
PartialList strikes me as hard to follow and wasteful, I'm sure there is a
reason for it but I can't figure it out. 


-pvg

-----Original Message-----
From: Jason Hunter [mailto:jhunter@collab.net]
Sent: Wednesday, September 27, 2000 2:08 PM
To: Peter V. Gadjokov
Cc: 'Travers Waker'; jdom-interest@jdom.org
Subject: Re: [jdom-interest] Iterator.remove() is calling a
non-overloadedmethod to remove children from an element.


> It might be a little harder to fix than it looks, most 
> likely PartialList will have to provide its own Iterator 
> (or perhaps someone can write a ListView-type class that does 
. not replicate storage and is not so gory).

Yep.  It's not a trivial fix (thus it's in the TODO.txt file and not
already done in the code) but it's a pretty straightforward fix.  

-jh-

--__--__--

Message: 17
From: "Peter V. Gadjokov" <pvg@c-c-s.com>
To: "'philip.nelson@omniresources.com'" <philip.nelson@omniresources.com>,
jdom-interest@jdom.org
Subject: RE: [jdom-interest] Re: static data needs to be thread data for
multithreaded applications
Date: Wed, 27 Sep 2000 14:31:40 -0700
charset="iso-8859-1"


>Are you all thinking about using the getDocument to find locate the home
for
>the namespaces and or prefix mappings?  At the time NameSpace was written,
>there was a lot of discussion about the static hashtables but because
nobody
>wanted to maintain parent relationships, there was no way to put namespace
>information in the Document for any given element.  It seems this has
>changed since then.
[...]
>I apologize in advance but I don't understand what you mean by "lack of
>separation between namespace name and namespace declaration".  I think that
>the static variables in Namespace can't work on a server, or at least that
>it's more compromises that it's worth.  It does work in what I think would
>have to be the more common use case of many similar xml documents processed
>by a server app.  My use case is a problem.  I would think that
>serialization would be complicated as well.

By 'separation' I mean having separate classes that represent what the
infoset calls 'namespace name' (basically, just the URI, a globally unique
id that distinguished one namespace from another, regardless of document
context) and a namespace declaration (a namespace, with a document-specific
prefix used for serialization and a document specific scope). 

Namespace names need no centralized static storage. It could be useful if
you want to save memory and it allows identity comparison but the global
storage has other problems (concurrency issues, potential for unbounded
growth, etc). 

Namespace declarations are document-specific so they need no centralized
storage either. The prefix map could live in Document. I think you are
raising the issue of getting the Document if you only have an element -
typically, an Outputter that cares most about prefixes gets the Document so
it doesn't have the problem. The recent change to isRootElement, though,
allows for the addition of a trivial getDocument method on Element which
would simply walk the path to the root until it hits the root element, if
any, and then return the root element's document. 

So, what I'm talking about is this:

 - A Namespace (or NamespaceName) class that is just the URI. This class has
a fast .equals method but does not rely on identity comparison. A sync'ed
Namespace.intern() method can be provided to trade performance for memory,
potentially, the parser can have an option to intern every NamespaceName it
encounters. 

- A NamespaceDeclaration class that is typically stored in an Element. It
describes the binding of a prefix to a NamespaceName and the scope of the
Namespace (which is the inclusive scope of the Element). 

- Facilities on Document and/or Element that let you 
   - look up the NamespaceName given a prefix and a scope (Element)
   - find the in-scope (i.e. both declared and 'inherited'
declarations)NamespaceDeclarations of a given Element

- Magic that shuffles conflicting or redundant namespace declarations when
Elements are moved within or between Documents. This could end up being
somewhat slow. I'd say make it 'deferrable', i.e. allow (optionally?) NS
declarations to be 'out of sync' after a move until something like
Document.notmalizeNSDeclarations() is called. 


If this covers the needs of NS handling (a big if, granted, but if it
doesn't I'm sure we'll hear about it), I don't think it actually needs
global static data anywhere. 

-pvg

--__--__--

Message: 18
Date: Wed, 11 Oct 2000 08:59:57 -0500
From: Perry Hoekstra <dutchman@uswest.net>
Organization: Talent Software Services
To: jdom-interest@jdom.org
Subject: [jdom-interest] xml:lang Attribute problem

Greet the sun all:

I don't if this is how I implemented it or a bug but when I execute the
following code:

StringBuffer t_xml = new StringBuffer("<?xml version = \"1.0\"?>");

t_xml.append("<Foo xml:lang=\"en-US\">  ");
t_xml.append("</Foo");

org.jdom.input.SAXBuilder t_saxBuilder = new
org.jdom.input.SAXBuilder("org.apache.xerces.parsers.SAXParser");

org.jdom.Document t_jdomDocument = t_saxBuilder.build(new
java.io.StringReader(t_xml.toString()));

I receive the following exception:

org.jdom.JDOMException: The name "" is not legal for JDOM/XML
namespaces: Namespace URIs must be non-null and non-empty Strings..)

Now, looking at page 297 of the XML Bible, it states that xml:lang is a
valid attribute.  I refresh my code with a fresh extract through CVS
this morning. Ideas on what I am doing wrong?

-- 
Perry Hoekstra
E-Commerce Architect
Talent Software Services
dutchman@mn.uswest.net


--__--__--

_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com

End of jdom-interest Digest_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com

From martin.sandahl at atg.se  Thu Sep 28 23:39:07 2000
From: martin.sandahl at atg.se (Martin Sandahl)
Date: Fri Aug  6 17:05:03 2004
Subject: [jdom-interest] jdom document
Message-ID: <9CE1D330B52ED41186D0009027F09E72263759@excl1.atg.se>

Hi,
I have a question about org.jdom.document
When does it support the getSerializedForm() method?
Has anyone developed this method?
Kind regards
/ Martin


Martin Sandahl
AB Trav & Galopp
Distribuerade Spel och Partner
161 89 Stockholm

+46 8 627 22 03
+46 70 527 22 03


From jhunter at collab.net  Thu Sep 28 23:54:36 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:05:03 2004
Subject: [jdom-interest] bug in Element()  ?
References: <213B28F4301DD411A81300508B0CCCDA0810F0@WHNEXG01.hq.whn.com>
Message-ID: <39D43CAC.DF82FA96@collab.net>

> How is it possible to add a child element at a given index?

elt.getChildren().add(int, Object)

-jh-

P.S.  Next time you post please don't include the entire digest
message!!

From jhunter at collab.net  Fri Sep 29 00:00:50 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:05:03 2004
Subject: [jdom-interest] jdom document
References: <9CE1D330B52ED41186D0009027F09E72263759@excl1.atg.se>
Message-ID: <39D43E22.1A4FE4DD@collab.net>

> I have a question about org.jdom.document
> When does it support the getSerializedForm() method?
> Has anyone developed this method?

This has been talked about many times before.  Summary is it was a
placeholder while we figured out what we wanted to do, and consensus
seems to be we're removing it and replacing it with methods on a utility
class.  For more info, search for "getSerializedForm" in the archives. 
(Link's on jdom.org -- download a month of messages and CTRL-F to
search.  It's not slick but it works.)

-jh-

From jhunter at collab.net  Fri Sep 29 00:55:29 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:05:03 2004
Subject: [jdom-interest] Beta5 preview
Message-ID: <39D44AF1.7CB4ED4@collab.net>

Hi everyone,

I just built and packaged a JDOM beta5 candidate.  Please, if you have
time, download the package and make sure it looks reasonable.  I'm
simply just looking for an external sanity check before declaring it
*the* beta5.  For people who've kept up with what's in CVS, please run
it against your apps.  Verify things like line endings are correct. 
Write the list with any issues.

I put it on my site servlets.com to make clear this is unofficial.  As
soon as I get an OK from someone on Windows and an OK from someone on
Unix, then we'll make this the official beta5 for download from
jdom.org.  :-)

http://www.servlets.com/outgoing-jdom/

Thanks!
-jh-

From jozart at csi.com  Fri Sep 29 03:36:11 2000
From: jozart at csi.com (Joseph Bowbeer)
Date: Fri Aug  6 17:05:03 2004
Subject: [jdom-interest] beta5 comments
Message-ID: <000901c02a01$1f172bc0$258a7cce@REPLICANT>

I downloaded jdom-complete.zip today and gave it a whirl.  It's been
about 6 weeks since I updated last.  Because this is a beta5 candidate,
I jotted down a few notes:

1. Building.  Both build.bat and build11.bat work fine.

 * Note: To build for JDK1.1 using Java2, remove classes.zip from
ADDITIONALCLASSPATH.

 * Warning: If you run both build11.bat and build.bat, do a 'build
clean' after 'build11' and before 'build'.  Otherwise, the second
'build' won't do anything.

2. XMLOutputter.  Now that formatting is preserved, XMLOutputter is not
the pretty-printer it once was.  However, I need some kind of outputter
that will produce the same result whether the input document was
programmatically constructed (without formatting) or constructed from a
text file (with formatting).  What's the recommended procedure?

3. JDK1.1.  Even though I use the JDK1.1 build, I'm happy with leaving
JDK1.1 as a second-class build.  In other words, it's OK with me if the
beta5 release does *not* contain a pre-built JDK1.1 jdom.jar.  It's also
OK with me if the JDK1.1 build uses the same 'build' directory as
Java2 -- even though this can be a little confusing.  The way I see it:
Java2 was developed nearly 2 years ago so JDK1.1 users should have to
suffer -- and in fact most of use are already accustomed to doing so.
Instead of tidying-up the JDK1.1 build, I'd rather see the extra effort
applied toward mainline development.

4. Thanks!  Aside from the XMLOutputter nit above, the beta5 candidate
works for me.

--
Joe Bowbeer




From sware at decadesystems.com  Fri Sep 29 04:43:28 2000
From: sware at decadesystems.com (Scott Ware)
Date: Fri Aug  6 17:05:03 2004
Subject: [jdom-interest] jdom document
References: <9CE1D330B52ED41186D0009027F09E72263759@excl1.atg.se> <39D43E22.1A4FE4DD@collab.net>
Message-ID: <002601c02a0a$7c69c540$3d02000a@sware>

Is there a JDOM schema validator?

----- Original Message -----
From: "Jason Hunter" <jhunter@collab.net>
To: "Martin Sandahl" <martin.sandahl@atg.se>
Cc: "J DOM - interest (E-mail)" <jdom-interest@jdom.org>
Sent: Friday, September 29, 2000 3:00 AM
Subject: Re: [jdom-interest] jdom document


> > I have a question about org.jdom.document
> > When does it support the getSerializedForm() method?
> > Has anyone developed this method?
>
> This has been talked about many times before.  Summary is it was a
> placeholder while we figured out what we wanted to do, and consensus
> seems to be we're removing it and replacing it with methods on a utility
> class.  For more info, search for "getSerializedForm" in the archives.
> (Link's on jdom.org -- download a month of messages and CTRL-F to
> search.  It's not slick but it works.)
>
> -jh-
> _______________________________________________
> To control your jdom-interest membership:
>
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com


From philip.nelson at omniresources.com  Fri Sep 29 05:46:32 2000
From: philip.nelson at omniresources.com (philip.nelson@omniresources.com)
Date: Fri Aug  6 17:05:03 2004
Subject: [jdom-interest] Bypassing Fetching DTD on JDom
Message-ID: <DF5018B3C986D11196FF0060089A903C2BFEDB@gbdev.omniresource.com>

> Sorry I tought that SAX in Jdom is just like jaxpi and is event based.
> Anyhow I used SAXBuilder instead of DOMBuilder but my problem 
> is still exists
> and
> SAXBuilder spend a ling time to fetching DTD like DOMBuilder.
> 

I should have given this a little more thought.  Yes it is the underlying
parser that is fetching the systemid.  No, the validate setting probably
doesn't matter because dtd's could have entity declarations which are used
regardless of whether the document is validated.  I didn't take the time to
see if there was any other feature of the underlying parser to help with
this but I doubt it because it wouldn't make sense for it attempt to do
that.  If the dtd had an entity declared and the document used the entity,
NOT processing the systemid would make the document parse fail.

Perhaps someone else can speak to this but I think you are going to have to
either change the system id to a file url when you are offline or not use
the document while offline.

From guru at edamame.stinky.com  Fri Sep 29 06:28:01 2000
From: guru at edamame.stinky.com (Alex Chaffee)
Date: Fri Aug  6 17:05:03 2004
Subject: [jdom-interest] PATCH: XMLOutputter refactoring/opening
Message-ID: <20000929062801.A21349@edamame.stinky.com>

I've patched XMLOutputter to make the following changes.  Please
integrate these into the version in the repository.

Added trimText property: will set whether the text is output verbatim
(false) or with whitespace stripped as per Element.getTextTrim().
Default: false

Updated documentation slightly

Made methods to print the inside of documents public, to wit:
  printComment
  printProcessingInstruction
  printDeclaration
  printDocType
  printCDATASection
  printElement

Made clean convenience wrappers for a few of the above; the rest take
indent parameters (which can be 0).

Refactored printElement so it calls printElementContent; slighly
cleaner if-then-else logic.

Made printElementContent public, in case you want to print just the
content of an element, and not the open/close tags.  (Believe it or
not, I had a need for this: printing an element whose content is an
HTML snippet, which could be mixed/nested content.)

Needs a bit of testing, esp. with namespaces (I'm no good at namespaces).

[Note: the setIndenting method seems redundant with setIndent(null) or
setIndent("") -- let's remove it?]

----------------

bash.exe-2.02$ cvs diff -u src/java/org/jdom/output/XMLOutputter.java
Index: src/java/org/jdom/output/XMLOutputter.java
===================================================================
RCS file: /home/cvspublic/jdom/src/java/org/jdom/output/XMLOutputter.java,v
retrieving revision 1.21
diff -u -r1.21 XMLOutputter.java
--- src/java/org/jdom/output/XMLOutputter.java	2000/09/20 00:30:40	1.21
+++ src/java/org/jdom/output/XMLOutputter.java	2000/09/29 13:41:21
@@ -97,6 +97,7 @@
  * @author Elliotte Rusty Harold
  * @author David & Will (from Post Tool Design)
  * @author Dan Schaffer
+ * @author Alex Chaffee (alex@jguru.com)
  * @version 1.0
  */
 public class XMLOutputter {
@@ -125,6 +126,9 @@
     /** New line separator */
     private String newline = "\r\n";
 
+    /** should we preserve whitespace or not? */
+    private boolean trimText = false;
+
     /**
      * <p>
      * This will create an <code>XMLOutputter</code> with
@@ -189,6 +193,16 @@
      * <p>
      *  This will set the new-line separator. The default is <code>\r\n</code>.
      * </p>
+     * <blockquote>
+     *  We could change this to the System default, 
+     *  but I prefer not to make output platform dependent.
+     *  A carriage return, linefeed pair is the most generally
+     *  acceptable linebreak.  Another possibility is to use
+     *  only a line feed, which is XML's preferred (but not required)
+     *  solution. However both carriage return and linefeed are
+     *  required for many network protocols, and the parser on the
+     *  other end should normalize this.  --Rusty
+     * </blockquote>
      *
      * @param separator <code>String</code> line separator to use.
      */
@@ -239,6 +253,17 @@
 
     /**
      * <p>
+     *  This will set whether the text is output verbatim (false) or with whitespace stripped as per Element.getTextTrim().  Default: false;
+     * </p>
+     *
+     * @param trimText <code>boolean</code> true=>trim the whitespace, false=>use text verbatim
+     */
+    public void setTrimText(boolean trimText) {
+        this.trimText = trimText;
+    }
+
+    /**
+     * <p>
      *   This will set the indent <code>String</code> to use; this is usually
      *    a <code>String</code> of empty spaces. Note that this will not affect the
      *    output if no indentation is being used. This can be set through
@@ -381,7 +406,7 @@
      * @param out <code>Writer</code> to write to.
      * @param indentLevel Current depth in hierarchy.
      */
-    protected void printComment(Comment comment,
+    public void printComment(Comment comment,
                                     Writer out, int indentLevel) throws IOException {
                                         
         indent(out, indentLevel);
@@ -399,7 +424,7 @@
      * @param out <code>Writer</code> to write to.
      * @param indentLevel Current depth in hierarchy.
      */
-    protected void printProcessingInstruction(ProcessingInstruction pi,
+    public void printProcessingInstruction(ProcessingInstruction pi,
                                     Writer out, int indentLevel) throws IOException {
                                         
         indent(out, indentLevel);
@@ -418,7 +443,7 @@
      * @param docType <code>DocType</code> whose declaration to write.
      * @param out <code>Writer</code> to write to.
      */
-    protected void printDeclaration(Document doc,
+    public void printDeclaration(Document doc,
                                     Writer out,
                                     String encoding)  throws IOException {
 
@@ -452,7 +477,7 @@
      * @param doc <code>Document</code> whose declaration to write.
      * @param out <code>Writer</code> to write to.
      */
-    protected void printDocType(DocType docType, Writer out)  throws IOException {
+    public void printDocType(DocType docType, Writer out)  throws IOException {
         if (docType == null) {
             return;
         }
@@ -491,7 +516,7 @@
      * @param out <code>Writer</code> to write to.
      * @param indent <code>int</code> level of indention.
      */
-    protected void printCDATASection(CDATA cdata,
+    public void printCDATASection(CDATA cdata,
 			      Writer out, int indentLevel) throws IOException {
 	
         indent(out, indentLevel);
@@ -503,14 +528,31 @@
     /**
      * <p>
      * This will handle printing out an <code>{@link Element}</code>,
-     *   its <code>{@link Attribute}</code>s, and its value.
+     *   its <code>{@link Attribute}</code>s, and its value, and all
+     *   contained (child) elements etc.
+     * </p>
+     *
+     * @param element <code>Element</code> to output.
+     * @param out <code>Writer</code> to write to.
+     **/
+    public void printElement(Element element, Writer out)
+	throws IOException
+    {
+	printElement(element, out, 0);
+    }
+    
+    /**
+     * <p>
+     * This will handle printing out an <code>{@link Element}</code>,
+     *   its <code>{@link Attribute}</code>s, and its value, and all
+     *   contained (child) elements etc.
      * </p>
      *
      * @param element <code>Element</code> to output.
      * @param out <code>Writer</code> to write to.
      * @param indent <code>int</code> level of indention.
      */
-    protected void printElement(Element element, Writer out,
+    public  void printElement(Element element, Writer out,
                                 int indentLevel)  throws IOException {
                                         
         // if this is the root element we could pre-initialize the namespace stack
@@ -565,6 +607,16 @@
 
         printAttributes(element.getAttributes(), element, out, namespaces);
 
+	// handle "" string same as empty
+	if (stringOnly) {
+            String elementText =
+		trimText ? element.getTextTrim() : element.getText();
+	    if (elementText == null ||
+		elementText.equals("")) {
+		empty = true;
+	    }
+	}
+	
         if (empty) {
             // Simply close up
             if (!expandEmptyElements) {
@@ -574,28 +626,79 @@
                 out.write(element.getQualifiedName());
                 out.write(">");
             }
+            maybePrintln(out);
+        } else {
+	    // we know it's not null or empty from above
+	    out.write(">");
+
+	    if (stringOnly) {
+		// if string only, print content on same line as tags
+		printElementContent(element, out, indentLevel, namespaces, mixedContent);
+	    }
+	    else {
+		maybePrintln(out);
+		printElementContent(element, out, indentLevel, namespaces, mixedContent);
+		indent(out, indentLevel);		
+	    }
+
+	    out.write("</");
+	    out.write(element.getQualifiedName());
+	    out.write(">");
+
             maybePrintln(out);
-        } else if (stringOnly) {
+	}
+
+	// remove declared namespaces from stack
+	while (namespaces.size() > previouslyDeclaredNamespaces) namespaces.pop();
+    }
+    
+    /**
+     * <p> This will handle printing out an <code>{@link
+     * Element}</code>'s content only, not including its tag,
+     * attributes, and namespace info.  </p>
+     *
+     * @param element <code>Element</code> to output.
+     * @param out <code>Writer</code> to write to.
+     * @param indent <code>int</code> level of indention.  */
+    public void printElementContent(Element element, Writer out)
+	throws IOException
+    {
+        List mixedContent = element.getMixedContent();
+	printElementContent(element, out, 0,
+			    new NamespaceStack(),
+			    mixedContent);
+    }
+
+    /**
+     * <p> This will handle printing out an <code>{@link
+     * Element}</code>'s content only, not including its tag,
+     * attributes, and namespace info.  </p>
+     *
+     * @param element <code>Element</code> to output.
+     * @param out <code>Writer</code> to write to.
+     * @param indent <code>int</code> level of indention.  */
+    protected void printElementContent(Element element, Writer out,
+				       int indentLevel,
+				       NamespaceStack namespaces,
+				       List mixedContent
+				       )  throws IOException
+    {
+	// get same local flags as printElement does
+	// a little redundant code-wise, but not performance-wise
+        boolean empty = mixedContent.size() == 0;
+        boolean stringOnly =
+            !empty &&
+            (mixedContent.size() == 1) &&
+            mixedContent.get(0) instanceof String;
+
+	if (stringOnly) {
             // Print the tag  with String on same line
             // Example: <tag name="value">content</tag>
-            // Also handle "" being added to content
-            String elementText = element.getText();
-            if ((elementText != null) && (!elementText.equals(""))) {
-                out.write(">");
-                out.write(escapeElementEntities(element.getText()));
-                out.write("</");
-                out.write(element.getQualifiedName());
-                out.write(">");
-            } else {
-                if (!expandEmptyElements) {     
-                    out.write(" />");
-                } else {
-                    out.write("></");
-                    out.write(element.getQualifiedName());
-                    out.write(">");
-                }
-            }
-            maybePrintln(out);
+            String elementText =
+		trimText ? element.getTextTrim() : element.getText();
+	    
+	    out.write(escapeElementEntities(elementText));
+	    
         } else {
             /**
              * Print with children on future lines
@@ -604,8 +707,6 @@
              *             <child/>
              *          </tag>
              */
-            out.write(">");
-            maybePrintln(out);
             // Iterate through children
             Object content = null;
             for (int i=0, size=mixedContent.size(); i<size; i++) {
@@ -626,19 +727,9 @@
                 } // Unsupported types are *not* printed
             }
 
-            indent(out, indentLevel);
-            out.write("</");
-            out.write(element.getQualifiedName());
-            out.write(">");
-            maybePrintln(out);
-
         }
+    }  // printElementContent
 
-        // remove declared namespaces from stack
-        while (namespaces.size() > previouslyDeclaredNamespaces) namespaces.pop();
-        
-    }
-    
     /**
      * <p>
      * This will handle printing out an <code>{@link Entity}</code>.

From guru at edamame.stinky.com  Fri Sep 29 06:31:18 2000
From: guru at edamame.stinky.com (Alex Chaffee)
Date: Fri Aug  6 17:05:03 2004
Subject: [jdom-interest] jdom document
In-Reply-To: <39D43E22.1A4FE4DD@collab.net>; from jhunter@collab.net on Fri, Sep 29, 2000 at 12:00:50AM -0700
References: <9CE1D330B52ED41186D0009027F09E72263759@excl1.atg.se> <39D43E22.1A4FE4DD@collab.net>
Message-ID: <20000929063118.B21349@edamame.stinky.com>

If my recent patch is accepted, that "utility class" is simply the
good old XMLOutputter.

Writer out = ...;
XMLOutputter xo = new XMLOutputter();
xo.printElement(element, out);

 - Alex

On Fri, Sep 29, 2000 at 12:00:50AM -0700, Jason Hunter wrote:
> > I have a question about org.jdom.document
> > When does it support the getSerializedForm() method?
> > Has anyone developed this method?
> 
> This has been talked about many times before.  Summary is it was a
> placeholder while we figured out what we wanted to do, and consensus
> seems to be we're removing it and replacing it with methods on a utility
> class.  For more info, search for "getSerializedForm" in the archives. 
> (Link's on jdom.org -- download a month of messages and CTRL-F to
> search.  It's not slick but it works.)
> 
> -jh-
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com

-- 
Alex Chaffee                       mailto:alex@jguru.com
jGuru - Java News and FAQs         http://www.jguru.com/alex/
Creator of Gamelan                 http://www.gamelan.com/
Founder of Purple Technology       http://www.purpletech.com/
Curator of Stinky Art Collective   http://www.stinky.com/

From guru at edamame.stinky.com  Fri Sep 29 06:37:29 2000
From: guru at edamame.stinky.com (Alex Chaffee)
Date: Fri Aug  6 17:05:03 2004
Subject: [jdom-interest] jdom document
In-Reply-To: <39D43E22.1A4FE4DD@collab.net>; from jhunter@collab.net on Fri, Sep 29, 2000 at 12:00:50AM -0700
References: <9CE1D330B52ED41186D0009027F09E72263759@excl1.atg.se> <39D43E22.1A4FE4DD@collab.net>
Message-ID: <20000929063729.C21349@edamame.stinky.com>

> > I have a question about org.jdom.document
> > When does it support the getSerializedForm() method?
> > Has anyone developed this method?

Sorry, I meant

String toMyFavoriteSerializedForm(Element element) {
 StringWriter sw = new StringWriter();
 XMLOutputter xo = new XMLOutputter();
 xo.printElement(element, sw);
 return sw.toString();
}

Note that the problem with having a single "getSerializedForm" method
is that there is no one canonical serialized form for any elemnt.  The
XMLOutputter has options for changing lots of things (whitespace,
indenting, etc. etc.).

I'd like to add some more methods to XMLOutputter, specifically

 public String outputString(Element) 

et al. -- but I thought I'd start with the basics.

 - A

-- 
Alex Chaffee                       mailto:alex@jguru.com
jGuru - Java News and FAQs         http://www.jguru.com/alex/
Creator of Gamelan                 http://www.gamelan.com/
Founder of Purple Technology       http://www.purpletech.com/
Curator of Stinky Art Collective   http://www.stinky.com/

From louisc at bu.edu  Fri Sep 29 07:53:37 2000
From: louisc at bu.edu (Louis Calisi)
Date: Fri Aug  6 17:05:03 2004
Subject: [jdom-interest] beta5 comments
References: <000901c02a01$1f172bc0$258a7cce@REPLICANT>
Message-ID: <39D4ACF1.AFE6A53D@bu.edu>

    Well I decided to give JDOM a whirl since the unofficial new beta is out. The
build script worked fine on my Irix machine. I also had no trouble converting my
project over to JDOM except for one snag which I think may be a bug.

    I'm building a JTree using XML and right now it only looks for the attribute
"name" in the tags to label the nodes in the JTree. Below is the relevant piece of
the code. I left out the recursive part for finding out if an element has children.
My program builds the structure of the JTree perfectly but it labels the nodes
wrong. I'm assuming the code bellow will label the nodes with the attribute called
name.


        while (i.hasNext()) {
            Element nd = (Element) i.next();
            node.add(new DefaultMutableTreeNode(
                nd.getAttributeValue("name"));
        }


    Part of the xml document that I am using looks like this:

<WORLD name="Earth"
    <HEMISPHERE name="North">
        <COUNTRY name="Germany"/>
........

    As it works now the code builds an JTree that looks like this:

World
  |
  |----Hemisphere
  |
  |------------- Country

.....

    Am I doing something wrong or is this a bug. Thanks in advance for any help
anyone can offer.


Louis Calisi




From Brad.Morgan at e-pubcorp.com  Fri Sep 29 08:07:38 2000
From: Brad.Morgan at e-pubcorp.com (Brad Morgan)
Date: Fri Aug  6 17:05:03 2004
Subject: [jdom-interest] beta5 comments
In-Reply-To: <000901c02a01$1f172bc0$258a7cce@REPLICANT>
Message-ID: <NDBBLFGNKKGCBIJEAIJBMEBNCHAA.Brad.Morgan@e-pubcorp.com>

I've submitted an XMLOutputter that solves problem #2.  Powers that be are
ignoring me but maybe it will work for you as well.  I've attached a copy.

Regards,

Brad

-----Original Message-----
From: jdom-interest-admin@jdom.org
[mailto:jdom-interest-admin@jdom.org]On Behalf Of Joseph Bowbeer
Sent: Friday, September 29, 2000 4:36 AM
To: jdom-interest@jdom.org
Subject: [jdom-interest] beta5 comments


I downloaded jdom-complete.zip today and gave it a whirl.  It's been
about 6 weeks since I updated last.  Because this is a beta5 candidate,
I jotted down a few notes:

1. Building.  Both build.bat and build11.bat work fine.

 * Note: To build for JDK1.1 using Java2, remove classes.zip from
ADDITIONALCLASSPATH.

 * Warning: If you run both build11.bat and build.bat, do a 'build
clean' after 'build11' and before 'build'.  Otherwise, the second
'build' won't do anything.

2. XMLOutputter.  Now that formatting is preserved, XMLOutputter is not
the pretty-printer it once was.  However, I need some kind of outputter
that will produce the same result whether the input document was
programmatically constructed (without formatting) or constructed from a
text file (with formatting).  What's the recommended procedure?

3. JDK1.1.  Even though I use the JDK1.1 build, I'm happy with leaving
JDK1.1 as a second-class build.  In other words, it's OK with me if the
beta5 release does *not* contain a pre-built JDK1.1 jdom.jar.  It's also
OK with me if the JDK1.1 build uses the same 'build' directory as
Java2 -- even though this can be a little confusing.  The way I see it:
Java2 was developed nearly 2 years ago so JDK1.1 users should have to
suffer -- and in fact most of use are already accustomed to doing so.
Instead of tidying-up the JDK1.1 build, I'd rather see the extra effort
applied toward mainline development.

4. Thanks!  Aside from the XMLOutputter nit above, the beta5 candidate
works for me.

--
Joe Bowbeer



_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: XMLOutputter.java
Type: application/octet-stream
Size: 35058 bytes
Desc: not available
Url : http://jdom.org/pipermail/jdom-interest/attachments/20000929/b75385e0/XMLOutputter.obj
From guru at edamame.stinky.com  Fri Sep 29 08:03:24 2000
From: guru at edamame.stinky.com (Alex Chaffee)
Date: Fri Aug  6 17:05:03 2004
Subject: [jdom-interest] beta5 comments
In-Reply-To: <000901c02a01$1f172bc0$258a7cce@REPLICANT>; from jozart@csi.com on Fri, Sep 29, 2000 at 03:36:11AM -0700
References: <000901c02a01$1f172bc0$258a7cce@REPLICANT>
Message-ID: <20000929080324.B21521@edamame.stinky.com>

> 2. XMLOutputter.  Now that formatting is preserved, XMLOutputter is not
> the pretty-printer it once was.  However, I need some kind of outputter
> that will produce the same result whether the input document was
> programmatically constructed (without formatting) or constructed from a
> text file (with formatting).  What's the recommended procedure?

Do you mean the whitespace issue?  If you want the XMLOutputter to
trim whitespace from text nodes, then apply my patch and call
xo.setTrimText(true) -- then it will look the same no matter how the
source was "formatted".  

Note that I am *not* recommending we put that patch in beta 5, since
it hasn't been tested/vetted.

 - A

-- 
Alex Chaffee                       mailto:alex@jguru.com
jGuru - Java News and FAQs         http://www.jguru.com/alex/
Creator of Gamelan                 http://www.gamelan.com/
Founder of Purple Technology       http://www.purpletech.com/
Curator of Stinky Art Collective   http://www.stinky.com/

From jhunter at collab.net  Fri Sep 29 10:33:18 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:05:03 2004
Subject: [jdom-interest] [Fwd: bug in Element.java]
Message-ID: <39D4D25E.8D8AF5EC@collab.net>

Bug report...

-jh-
-------------- next part --------------
An embedded message was scrubbed...
From: Jerry Lawson <jerry.lawson@virtualsummit.com>
Subject: bug in Element.java
Date: Fri, 29 Sep 2000 11:54:51 -0500
Size: 3102
Url: http://jdom.org/pipermail/jdom-interest/attachments/20000929/253f1bc4/attachment.eml
From jhunter at collab.net  Fri Sep 29 10:57:43 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:05:03 2004
Subject: [jdom-interest] beta5 comments
References: <000901c02a01$1f172bc0$258a7cce@REPLICANT>
Message-ID: <39D4D817.45B74050@collab.net>

> I downloaded jdom-complete.zip today and gave it a whirl.  
> It's been about 6 weeks since I updated last.  Because this is a 
> beta5 candidate,

Well, jdom-complete isn't the beta candidate.  The URL to get the beta
candidate was in my earlier message (Servlets.com/outgoing-jdom).

>  * Warning: If you run both build11.bat and build.bat, do a 'build
> clean' after 'build11' and before 'build'.  Otherwise, the second
> 'build' won't do anything.

Yep.  BTW, there's a really minor bug in this area.  If "java" runs JDK
1.1, but you set JAVA_HOME to point at JDK 1.2, then the antRun script
will still run the standard "java" JDK 1.1 binary ignoring JAVA_HOME. 
Looks like it's actually a bug in the "Java" task.  It may be tricky to
fix (haven't checked it out).

> 2. XMLOutputter.  Now that formatting is preserved, XMLOutputter is not
> the pretty-printer it once was.  However, I need some kind of outputter
> that will produce the same result whether the input document was
> programmatically constructed (without formatting) or constructed from a
> text file (with formatting).  What's the recommended procedure?

Alex looks to have fixed this (tho the patch isn't going into beta5).

-jh-

From jozart at csi.com  Fri Sep 29 11:45:33 2000
From: jozart at csi.com (Joseph Bowbeer)
Date: Fri Aug  6 17:05:03 2004
Subject: [jdom-interest] beta5 comments
References: <000901c02a01$1f172bc0$258a7cce@REPLICANT> <20000929080324.B21521@edamame.stinky.com>
Message-ID: <007701c02a45$9bd19e90$3c03b70a@REPLICANT>

Yes, I mean the whitespace issue.

I need to use XMLOutputter as a pretty-printer, and the patched
XMLOutputter should do the trick.  (Currently I have to keep track of
whether the document already contains indentation and new lines -- or
not.)

Q: Wouldn't it be preferable in some cases to also enhance the builder
side to optionally remove whitespace?


----- Original Message -----
From: "Alex Chaffee" <guru@edamame.stinky.com>
To: "Joseph Bowbeer" <jozart@csi.com>
Cc: <jdom-interest@jdom.org>
Sent: Friday, September 29, 2000 8:03 AM
Subject: Re: [jdom-interest] beta5 comments

Do you mean the whitespace issue?  If you want the XMLOutputter to
trim whitespace from text nodes, then apply my patch and call
xo.setTrimText(true) -- then it will look the same no matter how the
source was "formatted".




From louisc at bu.edu  Fri Sep 29 11:56:57 2000
From: louisc at bu.edu (Louis Calisi)
Date: Fri Aug  6 17:05:03 2004
Subject: [jdom-interest] beta5 comments
References: <000901c02a01$1f172bc0$258a7cce@REPLICANT> <39D4D817.45B74050@collab.net>
Message-ID: <39D4E5F9.B6D1E4C3@bu.edu>

> Alex looks to have fixed this (tho the patch isn't going into beta5).

    Any idea when this would be implemented? This is a necessary feature for me. It
would be possible for me to use getTextTrim() but in beta5 this also returns the
element's name.


From jhunter at collab.net  Fri Sep 29 12:09:55 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:05:03 2004
Subject: [jdom-interest] beta5 comments
References: <000901c02a01$1f172bc0$258a7cce@REPLICANT> <20000929080324.B21521@edamame.stinky.com> <007701c02a45$9bd19e90$3c03b70a@REPLICANT>
Message-ID: <39D4E903.FB5D2CE7@collab.net>

> Yes, I mean the whitespace issue.
> 
> I need to use XMLOutputter as a pretty-printer, and the patched
> XMLOutputter should do the trick.  (Currently I have to keep track of
> whether the document already contains indentation and new lines -- or
> not.)

Cool, please if you could, add the patch and let us know if it works. 
Alex says he didn't do real testing, so we're waiting a little on
integration until someone gives it a run-through (I'm booked --
literally, with writing my book).

> Q: Wouldn't it be preferable in some cases to also enhance the builder
> side to optionally remove whitespace?

Yep.  It's in the TODO.  XML purists are going to scream.

-jh-

From Brad.Morgan at e-pubcorp.com  Fri Sep 29 13:28:59 2000
From: Brad.Morgan at e-pubcorp.com (Brad Morgan)
Date: Fri Aug  6 17:05:03 2004
Subject: [jdom-interest] beta5 comments
In-Reply-To: <39D4E903.FB5D2CE7@collab.net>
Message-ID: <NDBBLFGNKKGCBIJEAIJBIECCCHAA.Brad.Morgan@e-pubcorp.com>

Once Alex's patch is in the library, you shouldn't have to keep track of the
state of the document.  You have two choices, 1) keep the old whitespace or
2) remove it and add new.  It doesn't need to be removed by the builder
because the patched XMLOutputter will do
the right thing.  The rest of JDOM doesn't care if its there or not.

Brad Morgan
e-Publishing Corp.

Email: Brad.Morgan@e-pubcorp.com
Phone: (719)593-7377 x35
Fax: (719)593-2996

-----Original Message-----
From: jdom-interest-admin@jdom.org
[mailto:jdom-interest-admin@jdom.org]On Behalf Of Jason Hunter
Sent: Friday, September 29, 2000 1:10 PM
To: Joseph Bowbeer
Cc: alex@jguru.com; jdom-interest@jdom.org
Subject: Re: [jdom-interest] beta5 comments


> Yes, I mean the whitespace issue.
>
> I need to use XMLOutputter as a pretty-printer, and the patched
> XMLOutputter should do the trick.  (Currently I have to keep track of
> whether the document already contains indentation and new lines -- or
> not.)

Cool, please if you could, add the patch and let us know if it works.
Alex says he didn't do real testing, so we're waiting a little on
integration until someone gives it a run-through (I'm booked --
literally, with writing my book).

> Q: Wouldn't it be preferable in some cases to also enhance the builder
> side to optionally remove whitespace?

Yep.  It's in the TODO.  XML purists are going to scream.

-jh-
_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com


From jhunter at collab.net  Fri Sep 29 13:29:32 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:05:03 2004
Subject: [jdom-interest] beta5 comments
References: <NDBBLFGNKKGCBIJEAIJBIECCCHAA.Brad.Morgan@e-pubcorp.com>
Message-ID: <39D4FBAC.B11A49E9@collab.net>

Brad Morgan wrote:
> 
> Once Alex's patch is in the library, you shouldn't have to keep 
> track of the state of the document.  You have two choices, 1) keep 
> the old whitespace or 2) remove it and add new.  
> It doesn't need to be removed by the builder
> because the patched XMLOutputter will do
> the right thing.  

It's a memory issue.  Stripping whitespace is an easy memory saver (we
could do fancy compression, but that's much more complicated, esp
considering some parsers will do the whitespace stripping for you).

-jh-

From jhunter at collab.net  Fri Sep 29 15:36:48 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:05:04 2004
Subject: [jdom-interest] META: Children of a lesser spec
References: <704ECFDA88B3D311B5F000A0C959E5B601FBEC@adobo.c2labs.com> <39C35189.E2F0EB22@lutris.com>
Message-ID: <39D51980.45F74B28@collab.net>

Little follow-up on the getChild/getChildElement debate.  :-)

Brett McLaughlin wrote:
> 
> > >Now, if it was only correct. But it isn't, and a cursory 
> > >reading of any XML specification makes it confusing, 
> > > especially getChildren()...

> Even on these grounds, you will find
> that XML Infoset clearly defines content, and children.
> 
> >From that spec:
> 
> <<<<<<<<<<<<<
> 
> An element information item has the following properties:
> 
> ...
> 
> 3.[children] An ordered list of child information items, in document
> order. This list contains element , processing instruction, 
> reference to skipped entity, character, and comment information
> items, one for each element, processing instruction,
> reference to an unprocessed external entity,
> data character. and comment appearing immediately within
> the current element, .....

I think it's good to ask which specs we want to use for terminology. 
For example, looking at the XML 1.0 spec I see this production rule:

  [46] contentspec ::= 'EMPTY' | 'ANY' | Mixed | children 
  [47] children ::= (choice | seq) ('?' | '*' | '+')?

You could see this as an example where the XML spec refers to the
exclusive set of subelements as "children" not "childElements".  
What does XML call "children"?  See production rule 47.  It's only
elements.

Also, in Infoset I see this:

   2.3.1. Attributes: Core Properties

   An attribute information item must have the following 
   properties available in some form:

   1.[namespace URI] The URI part, if any, of the attribute's name. 
   2.[local name] The local part of the attribute's name. This does 
   not include any namespace prefix or following colon. 
   3.[children] An ordered list of references to character 
   information items, one for each character appearing in the 
   normalized attribute value. 

This makes me think that if we went with 100% Infoset terminology then
instead of Attribute.getValue() it needs to be Attribute.getChildren()
-- returning the characters which by this terminology are called
children.  I think we can all agree (hopefully) that that's ridiculous.

For a final example, let's look at the XPath spec:

 child::* selects all element children of the context node
 child::text() selects all text node children of the context node
 child::node() selects all the children of the context node, whatever
 their node type

Pretty clear that child::* returns only *element* children.  You use
child::node() to return a list of all types.  When XPath says "child" it
also means element children.

So the XML 1.0 spec has production rules 46/47 which refer to "children"
to mean only "direct subelements".  The Infoset spec is clear as Brett
said, but because of its odd naming conventions regarding children in
the attribute case, I could easily argue we're not honor bound to follow
its terminology exactly.  And XPath clearly has child::* refer to
elements only.

Bottom line: as I stated earlier, I prefer the elegance of getChild /
getChildren over getChildElement / getChildElements.  It matches nicely
with getParent.  It seems less redundant.  It's easier to differentiate
singular from plural.  The problem has always been spec terminology, and
looking at three XML specs today I don't think we'd be in gross
violation using getChild instead of getChildElement, and using the
simpler name definitely "fits" better with the API and I see that as
more important than being robotically precise and including the return
type within the method name.

OK, back to real work.

-jh-

From brett.mclaughlin at lutris.com  Fri Sep 29 17:17:44 2000
From: brett.mclaughlin at lutris.com (Brett McLaughlin)
Date: Fri Aug  6 17:05:04 2004
Subject: [jdom-interest] META: Children of a lesser spec
References: <704ECFDA88B3D311B5F000A0C959E5B601FBEC@adobo.c2labs.com> <39C35189.E2F0EB22@lutris.com> <39D51980.45F74B28@collab.net>
Message-ID: <39D53128.35AE9F6E@lutris.com>


Jason Hunter wrote:
> 
> Little follow-up on the getChild/getChildElement debate.  :-)
> 
> Brett McLaughlin wrote:
> >
> > > >Now, if it was only correct. But it isn't, and a cursory
> > > >reading of any XML specification makes it confusing,
> > > > especially getChildren()...
> 
> > Even on these grounds, you will find
> > that XML Infoset clearly defines content, and children.
> >
> > >From that spec:
> >
> > <<<<<<<<<<<<<
> >
> > An element information item has the following properties:
> >
> > ...
> >
> > 3.[children] An ordered list of child information items, in document
> > order. This list contains element , processing instruction,
> > reference to skipped entity, character, and comment information
> > items, one for each element, processing instruction,
> > reference to an unprocessed external entity,
> > data character. and comment appearing immediately within
> > the current element, .....
> 
> I think it's good to ask which specs we want to use for terminology.
> For example, looking at the XML 1.0 spec I see this production rule:
> 
>   [46] contentspec ::= 'EMPTY' | 'ANY' | Mixed | children
>   [47] children ::= (choice | seq) ('?' | '*' | '+')?
> 
> You could see this as an example where the XML spec refers to the
> exclusive set of subelements as "children" not "childElements".
> What does XML call "children"?  See production rule 47.  It's only
> elements.

Yes, and no. What you've pointed out is correct; however, you've found
an inconsistency in the spec, as compared to other specs (yes, this is a
major problem)! As I've always said, getChildren() is not "just
horrible" - it's perfectly sensible from the Java point of view, and
pretty muddled from the XML point of view. I guess as that is the case,
I would rather avoid confusion in both cases.

See, the way I look at it, getChild()/getChildren() is clear for Java,
and muddy for XML.
But getChildElement()/getChildElements() is clear for both Java and XML,
albeit a little inconvenient for Java.

I can't see how it's bad to be a little inconvenient to make it clear
for all; however, it's only fair to say that because of my work and
book, I deal with Java people and XML people equally. Many of you are
exclusively on the Java side, and this may be onerous...

ahhh... tiring... tiring ;-)

-Brett

> 
> Also, in Infoset I see this:
> 
>    2.3.1. Attributes: Core Properties
> 
>    An attribute information item must have the following
>    properties available in some form:
> 
>    1.[namespace URI] The URI part, if any, of the attribute's name.
>    2.[local name] The local part of the attribute's name. This does
>    not include any namespace prefix or following colon.
>    3.[children] An ordered list of references to character
>    information items, one for each character appearing in the
>    normalized attribute value.
> 
> This makes me think that if we went with 100% Infoset terminology then
> instead of Attribute.getValue() it needs to be Attribute.getChildren()
> -- returning the characters which by this terminology are called
> children.  I think we can all agree (hopefully) that that's ridiculous.
> 
> For a final example, let's look at the XPath spec:
> 
>  child::* selects all element children of the context node
>  child::text() selects all text node children of the context node
>  child::node() selects all the children of the context node, whatever
>  their node type
> 
> Pretty clear that child::* returns only *element* children.  You use
> child::node() to return a list of all types.  When XPath says "child" it
> also means element children.
> 
> So the XML 1.0 spec has production rules 46/47 which refer to "children"
> to mean only "direct subelements".  The Infoset spec is clear as Brett
> said, but because of its odd naming conventions regarding children in
> the attribute case, I could easily argue we're not honor bound to follow
> its terminology exactly.  And XPath clearly has child::* refer to
> elements only.
> 
> Bottom line: as I stated earlier, I prefer the elegance of getChild /
> getChildren over getChildElement / getChildElements.  It matches nicely
> with getParent.  It seems less redundant.  It's easier to differentiate
> singular from plural.  The problem has always been spec terminology, and
> looking at three XML specs today I don't think we'd be in gross
> violation using getChild instead of getChildElement, and using the
> simpler name definitely "fits" better with the API and I see that as
> more important than being robotically precise and including the return
> type within the method name.
> 
> OK, back to real work.
> 
> -jh-

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org

From guru at edamame.stinky.com  Fri Sep 29 17:22:13 2000
From: guru at edamame.stinky.com (Alex Chaffee)
Date: Fri Aug  6 17:05:04 2004
Subject: [jdom-interest] META: Children of a lesser spec
In-Reply-To: <39D51980.45F74B28@collab.net>; from jhunter@collab.net on Fri, Sep 29, 2000 at 03:36:48PM -0700
References: <704ECFDA88B3D311B5F000A0C959E5B601FBEC@adobo.c2labs.com> <39C35189.E2F0EB22@lutris.com> <39D51980.45F74B28@collab.net>
Message-ID: <20000929172213.A23706@edamame.stinky.com>

> Bottom line: as I stated earlier, I prefer the elegance of getChild /
> getChildren over getChildElement / getChildElements. 

Jason, I completely agree with your reasoning in this message.  I even
feel (strongly) that getChild() is better than getChildElement().  But
why do you refuse to acknowledge the third option, getElement()?

This project needs a third-party candidate!  For too long we have
suffered with the false choice between Brettocrats and Huntericans.

Your campaign managers said you would debate anywhere, anytime!  

Oh no, wait, that wasn't you.  It wasn't me, either.

OK, back to taking a nap.

 - A

-- 
Alex Chaffee                       mailto:alex@jguru.com
jGuru - Java News and FAQs         http://www.jguru.com/alex/
Creator of Gamelan                 http://www.gamelan.com/
Founder of Purple Technology       http://www.purpletech.com/
Curator of Stinky Art Collective   http://www.stinky.com/

From jhunter at collab.net  Fri Sep 29 17:47:44 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:05:04 2004
Subject: [jdom-interest] META: Children of a lesser spec
References: <704ECFDA88B3D311B5F000A0C959E5B601FBEC@adobo.c2labs.com> <39C35189.E2F0EB22@lutris.com> <39D51980.45F74B28@collab.net> <20000929172213.A23706@edamame.stinky.com>
Message-ID: <39D53830.D0AF15B6@collab.net>

> Jason, I completely agree with your reasoning in this message.  I even
> feel (strongly) that getChild() is better than getChildElement().  

OK, so I have a +1 if I can get rid of the third party candidate.  :-)

> But why do you refuse to acknowledge the third option, getElement()?

Because I don't like elt.getElement("foo").getElement("bar").  It's too
ambiguous.  I wouldn't like str.getString() either, or obj.getObject().

> This project needs a third-party candidate!  For too long we have
> suffered with the false choice between Brettocrats and Huntericans.

Go Nader, eh?

> OK, back to taking a nap.

You need a job, Alex.  Barring that, we need you to do more JDOM work! 
Keep up with the patches!  :-)

-jh-

From mikeb at cybersource.com  Fri Sep 29 09:47:28 2000
From: mikeb at cybersource.com (Blanton, Mike)
Date: Fri Aug  6 17:05:04 2004
Subject: [jdom-interest] Possible bug in Element getText()?
Message-ID: <31F57C58C456D411AA4D00B0D03D97CD1319D6@mtv-exch01.cybersource.com>

Using the latest code from CVS (as of yesterday afternoon), I've got some
code that processes an XML document with a field <Qty/>.  In this particular
case, wouldn't the Element function getText() (and it's variants) return
null?  When I try it, all of those functions throw Null Pointer Exceptions.
I'm using the SAX Builder to build my document.

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://jdom.org/pipermail/jdom-interest/attachments/20000929/42e64d40/attachment.htm
From guru at edamame.stinky.com  Fri Sep 29 19:32:03 2000
From: guru at edamame.stinky.com (Alex Chaffee)
Date: Fri Aug  6 17:05:04 2004
Subject: [jdom-interest] beta5 comments
In-Reply-To: <39D4E903.FB5D2CE7@collab.net>; from jhunter@collab.net on Fri, Sep 29, 2000 at 12:09:55PM -0700
References: <000901c02a01$1f172bc0$258a7cce@REPLICANT> <20000929080324.B21521@edamame.stinky.com> <007701c02a45$9bd19e90$3c03b70a@REPLICANT> <39D4E903.FB5D2CE7@collab.net>
Message-ID: <20000929193203.D23706@edamame.stinky.com>

> Alex says he didn't do real testing, so we're waiting a little on
> integration until someone gives it a run-through 

I tested it (successfully) a bit on my side, and I didn't change the
logic of output(Document) -- just refactored.  Maybe it'd be better to
put it in, then let people complain if it breaks -- the tried-and-true
Apache method. :-)

I thought of a case this morning (in the shower, actually) where I'll
need to test, but it's when calling public printElement() directly on
an element some of whose children use the same namespace as the
parent, which I think at present will, um, I'm not sure actually what
it would do, or what it should do either, which is one reason I
haven't tested it.  I'm not really clear on what the namespaceStack is
for precisely... (other than storing namespaces :-)) or how/whether to
look *up* the node tree for a namespace declaration if we're
outputting a child element with an unknown namespace...

 - A

-- 
Alex Chaffee                       mailto:alex@jguru.com
jGuru - Java News and FAQs         http://www.jguru.com/alex/
Creator of Gamelan                 http://www.gamelan.com/
Founder of Purple Technology       http://www.purpletech.com/
Curator of Stinky Art Collective   http://www.stinky.com/

From jhunter at collab.net  Fri Sep 29 19:58:34 2000
From: jhunter at collab.net (Jason Hunter)
Date: Fri Aug  6 17:05:04 2004
Subject: [jdom-interest] beta5 comments
References: <000901c02a01$1f172bc0$258a7cce@REPLICANT> <20000929080324.B21521@edamame.stinky.com> <007701c02a45$9bd19e90$3c03b70a@REPLICANT> <39D4E903.FB5D2CE7@collab.net> <20000929193203.D23706@edamame.stinky.com>
Message-ID: <39D556DA.A7258778@collab.net>

> > Alex says he didn't do real testing, so we're waiting a little on
> > integration until someone gives it a run-through
> 
> I tested it (successfully) a bit on my side

OK, I'll integrate it as soon as we declare beta5.  

BTW, only one person has checked out the beta so far.  Do you all figure
someone else will do it?

-jh-

From brett.mclaughlin at lutris.com  Fri Sep 29 20:53:26 2000
From: brett.mclaughlin at lutris.com (Brett McLaughlin)
Date: Fri Aug  6 17:05:04 2004
Subject: [jdom-interest] beta5 comments
References: <000901c02a01$1f172bc0$258a7cce@REPLICANT> <20000929080324.B21521@edamame.stinky.com> <007701c02a45$9bd19e90$3c03b70a@REPLICANT> <39D4E903.FB5D2CE7@collab.net> <20000929193203.D23706@edamame.stinky.com> <39D556DA.A7258778@collab.net>
Message-ID: <39D563B6.93AC9EFF@lutris.com>


Jason Hunter wrote:
> 
> > > Alex says he didn't do real testing, so we're waiting a little on
> > > integration until someone gives it a run-through
> >
> > I tested it (successfully) a bit on my side
> 
> OK, I'll integrate it as soon as we declare beta5.

Don't until we get the issue with intermittent white-space. I agree
that's a little weird... Probably should be a separate option.

-Brett

> 
> BTW, only one person has checked out the beta so far.  Do you all figure
> someone else will do it?
> 
> -jh-
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org

From dutchman at uswest.net  Sat Sep 30 05:27:18 2000
From: dutchman at uswest.net (Perry Hoekstra)
Date: Fri Aug  6 17:05:04 2004
Subject: [jdom-interest] beta5 comments
References: <000901c02a01$1f172bc0$258a7cce@REPLICANT> <20000929080324.B21521@edamame.stinky.com> <007701c02a45$9bd19e90$3c03b70a@REPLICANT> <39D4E903.FB5D2CE7@collab.net> <20000929193203.D23706@edamame.stinky.com> <39D556DA.A7258778@collab.net>
Message-ID: <39D5DC26.74751918@mn.uswest.net>


Jason Hunter wrote:
 
> BTW, only one person has checked out the beta so far.  Do you all figure
> someone else will do it?

We have implemented it and are currently testing our system running with
it.  The system will be moving to integration test Tuesday with beta 5
as part of it

-- 
Perry Hoekstra
E-Commerce Architect
Talent Software Service
dutchman@mn.uswest.net

From guru at edamame.stinky.com  Sat Sep 30 11:23:08 2000
From: guru at edamame.stinky.com (Alex Chaffee)
Date: Fri Aug  6 17:05:04 2004
Subject: [jdom-interest] XMLOutputter naming questions
Message-ID: <20000930112308.F23706@edamame.stinky.com>

In addition to my patch, I'd like to make a few cosmetic changes to
XMLOutputter.  I thought I'd ask the list if anyone objects to the
following:

- remove setIndenting() -- it's redundant with setIndent() and
confusing to boot.  Why should I have to call setIndenting(true) if I
just called setIndent(" ")?  Likewise, if I call setIndenting(true)
why should I then also have to call setIndent(" ") before any
indenting will happen?

  I'd like the semantics to be 
	setIndent(null) -> no indenting
	setIndent("") -> no indenting
	setIndent("  ") -> enable indenting 

 Is anyone really in love with setIndenting(true)?  (If so, we could
 make it wrap setIndent(" ") or someting sensible.)


- remove the method output(Document, OutputStream, String encoding).
Instead, if people want to output a different encoding, they should
just call
  outputter.setEncoding(foo);
  outputter.output(doc, out);

(of course, that depends on there being a setEncoding method, which I
just added :-)

  this will make the API clearer and the internal logic a little
neater for another improvement I'm adding, namely...


- allow the user to output to either a Writer or an
OutputStream. (Right now it's one or the other -- OutputStream to
print a document, Writer to print an element.)  This would have to be
documented as follows:

 Warning: using your own Writer may cause the outputter's preferred
 character encoding to be ignored.  If you use encodings other than
 UTF8, we recommend using the method that takes an OutputStream
 instead.


- add a method for outputting a string.  This would just wrap the
normal output() in a ByteArrayOutputStream.  Then we can use the same
formatter (and all its options) to output a (document or element) to a
(string or stream or writer).

I'd like opinions on the following naming conventions:

	void output(Document d, OutputStream out)
	void output(Element d, OutputStream out)
	String output(Document d)
	String output(Element e)

versus:

	void output(Document d, OutputStream out)
	void outputElement(Element d, OutputStream out)
	String outputString(Document d)
	String outputString(Element e)

versus:

	void output(Document d, OutputStream out)
	void output(Element d, OutputStream out)
	String outputString(Document d)
	String outputString(Element e)

Note that most of this is written already (on my machine); I just need
advice on the names.  I'm leaning towards the last one (output/output/outputString)

Thanks -

 - Alex

-- 
Alex Chaffee                       mailto:alex@jguru.com
jGuru - Java News and FAQs         http://www.jguru.com/alex/
Creator of Gamelan                 http://www.gamelan.com/
Founder of Purple Technology       http://www.purpletech.com/
Curator of Stinky Art Collective   http://www.stinky.com/

From guru at edamame.stinky.com  Sat Sep 30 12:49:29 2000
From: guru at edamame.stinky.com (Alex Chaffee)
Date: Fri Aug  6 17:05:04 2004
Subject: [jdom-interest] XMLOutputter naming questions
In-Reply-To: <20000930112308.F23706@edamame.stinky.com>; from guru@edamame.stinky.com on Sat, Sep 30, 2000 at 11:23:08AM -0700
References: <20000930112308.F23706@edamame.stinky.com>
Message-ID: <20000930124929.H23706@edamame.stinky.com>

Just read TODO.txt: "Write
XMLOutputter.serialize(doc/elem/comment/doctype/entity/pi/attrib). Have
these methods replace getSerializedForm().  Going this way allows
tweaks to the XMLOutputter behavior before serialization."

I think "serialize" is the wrong word; "output" is better for this,
since it's consistent with the name of the object, isn't confused with
other meanings of "serialize," etc.

That means I should go ahead and write the following:

 	void output(Document d, OutputStream out)
 	void output(Element e, OutputStream out)
 	void output(Comment c, OutputStream out)
 	void output(Entity e, OutputStream out)
	etc.

Right?

That means I only need to know whether to go with

> 	String output(Document d)
> 	String output(Element e)
> 
> versus:
> 
> 	String outputString(Document d)
> 	String outputString(Element e)

Any votes?

 - AleXMLOutputter


-- 
Alex Chaffee                       mailto:alex@jguru.com
jGuru - Java News and FAQs         http://www.jguru.com/alex/
Creator of Gamelan                 http://www.gamelan.com/
Founder of Purple Technology       http://www.purpletech.com/
Curator of Stinky Art Collective   http://www.stinky.com/

From jozart at csi.com  Sat Sep 30 15:09:08 2000
From: jozart at csi.com (Joseph Bowbeer)
Date: Fri Aug  6 17:05:04 2004
Subject: [jdom-interest] XMLOutputter naming questions
Message-ID: <000701c02b2b$1995a700$258a7cce@REPLICANT>

Alex Chaffee wrote:

>> - add a method for outputting a string.  This would just wrap the
normal output() in a  ByteArrayOutputStream.  Then we can use the same
formatter (and all its options) to output a (document or element) to a
(string or stream or writer). <<

Alex,

Once you've added output(whatever, Writer), do you need to add extra
string methods?  Can't the user just pass-in a StringWriter instead?

I'm not clear on all the encoding complications, but in addition to the
obligatory toString() method, StringWriter provides getBuffer() to
return the underlying StringBuffer -- which could be more efficient in
some situations.

If output directly to String is desired, I favor tagging the method name
with the return type, since Java refuses to differentiate based solely
on return type.  So if you must, I prefer:

 String outputString(Document d)
 String outputString(Element e)

On the other hand, I don't see any need to append 'Element' as in
'outputElement'.  I prefer:

 void output(Document d, OutputStream out)
 void output(Element d, OutputStream out)

Other votes:

 +1 for getChild[ren]
 +0 for getChildElement[s]
 -1 for getElement[s]

--
Joe Bowbeer




From guru at edamame.stinky.com  Sat Sep 30 16:00:07 2000
From: guru at edamame.stinky.com (Alex Chaffee)
Date: Fri Aug  6 17:05:04 2004
Subject: [jdom-interest] XMLOutputter naming questions
In-Reply-To: <000701c02b2b$1995a700$258a7cce@REPLICANT>; from jozart@csi.com on Sat, Sep 30, 2000 at 03:09:08PM -0700
References: <000701c02b2b$1995a700$258a7cce@REPLICANT>
Message-ID: <20000930160007.A25911@edamame.stinky.com>

On Sat, Sep 30, 2000 at 03:09:08PM -0700, Joseph Bowbeer wrote:
> Alex Chaffee wrote:
> 
> >> - add a method for outputting a string.  This would just wrap the
> normal output() in a  ByteArrayOutputStream.  Then we can use the same
> formatter (and all its options) to output a (document or element) to a
> (string or stream or writer). <<
> 
> Alex,
> 
> Once you've added output(whatever, Writer), do you need to add extra
> string methods?  Can't the user just pass-in a StringWriter instead?
> 
> I'm not clear on all the encoding complications, but in addition to the
> obligatory toString() method, StringWriter provides getBuffer() to
> return the underlying StringBuffer -- which could be more efficient in
> some situations.

True.  I just feel that people will be asking "How do I turn an
element into a string?" and the easiest way is to answer with a single
method call.  You can always pass in a StringWriter to output() if you
desire.

As for encoding, I think Strings are chars are Unicode so encoding is
not an issue.


> If output directly to String is desired, I favor tagging the method name
> with the return type, since Java refuses to differentiate based solely
> on return type.  So if you must, I prefer:
> 
>  String outputString(Document d)
>  String outputString(Element e)
> 
> On the other hand, I don't see any need to append 'Element' as in
> 'outputElement'.  I prefer:
> 
>  void output(Document d, OutputStream out)
>  void output(Element d, OutputStream out)

Thanks for the input.  I agree.


-- 
Alex Chaffee                       mailto:alex@jguru.com
jGuru - Java News and FAQs         http://www.jguru.com/alex/
Creator of Gamelan                 http://www.gamelan.com/
Founder of Purple Technology       http://www.purpletech.com/
Curator of Stinky Art Collective   http://www.stinky.com/

From omenred at yahoo.com  Sat Sep 30 22:53:20 2000
From: omenred at yahoo.com (Omen Red)
Date: Fri Aug  6 17:05:04 2004
Subject: [jdom-interest] XMLOutputter naming questions
Message-ID: <20001001055320.2342.qmail@web2104.mail.yahoo.com>

Hi,
--- Alex Chaffee <guru@edamame.stinky.com> wrote:
> Just read TODO.txt: "Write
>
XMLOutputter.serialize(doc/elem/comment/doctype/entity/pi/attrib).
> Have
> these methods replace getSerializedForm().  Going
> this way allows
> tweaks to the XMLOutputter behavior before
> serialization."
> 
> That means I should go ahead and write the
> following:
> 
>  	void output(Document d, OutputStream out)
>  	void output(Element e, OutputStream out)
>  	void output(Comment c, OutputStream out)
>  	void output(Entity e, OutputStream out)
> 	etc.
> 
> Right?
> 
> That means I only need to know whether to go with
> 
> > 	String output(Document d)
> > 	String output(Element e)
> > 
> > versus:
> > 
> > 	String outputString(Document d)
> > 	String outputString(Element e)
> 
> Any votes?



As for me just "output" sounds shorter and nicer.
Besides "outputString" sounds redundant, Are you going
to return another type than String in future ???

Q: just little question, you mentioned 
>  	void output(Document d, OutputStream out)
>  	void output(Element e, OutputStream out)
>  	void output(Comment c, OutputStream out)
>  	void output(Entity e, OutputStream out)
functions above. Are you going to implement them as
public ? In case if yes maybe there is reason to add
also 
>  	void output(Document d, Writer out)
>  	void output(Element e, Writer out)
>  	void output(Comment c, Writer out)
>  	void output(Entity e, Writer out)
functions. Just proposal.

best regards,
Om.

__________________________________________________
Do You Yahoo!?
Yahoo! Photos - 35mm Quality Prints, Now Get 15 Free!
http://photos.yahoo.com/

From jmm at computer.org  Fri Sep 29 13:05:37 2000
From: jmm at computer.org (James Manning)
Date: Fri Aug  6 17:05:04 2004
Subject: [jdom-interest] XMLOutputter in nonewline mode
Message-ID: <20000929160537.A20158@bp6.sublogic.lan>

I built jdom from CVS and had it make my program die.  My program
assumes that XMLOutputter in nonewline mode will transmit the document
in a single line.  Unfortunately, a cr/lf was in the stream after the
<?xml ... ?> line.

could this get fixed?

Please cc: if at all possible, as I'm not on jdom-interest (yet :)

James
-- 
James Manning <jmm@computer.org>
GPG Key fingerprint = B913 2FBD 14A9 CE18 B2B7  9C8E A0BF B026 EEBB F6E4

From Jose_Sanchez at amsinc.com  Sat Sep  2 16:38:12 2000
From: Jose_Sanchez at amsinc.com (Jose_Sanchez@amsinc.com)
Date: Fri Aug  6 17:05:14 2004
Subject: [jdom-interest] Re: Validation Against Schemas
Message-ID: <8525698B.0082088D.00@ams-central-gate-5a.amsinc.com>


     Thanks very much Swaminathan and Celia for your help. I finally could
validate against schemas, I modified the SAXBuilder class as Swaminathan
suggested and everything went ok. Just two things:

     - Apparently jdom beta 5 has solved the problem and is able to validate
against schemas without even asking for it.
...and a dream
     - I hope that Schema will soon become a W3C recommnedation cause right now
the differences between vendors implementations of parsers makes it a nightmare
to work with schema. For example, I had to convert my valid schemas on Spy into
the format of the XERCES examples in order to make it work.

     One more question: Does anybody knows who to get out of a JDOMException or
SAXParseException the name of the attribute and/or element that caused the
exception? We are using the schema for form validation (comming from a GUI) and
would like to use that info to dinamically generate error messages for the user.
Thanks very much again,

                                              Jose