[jdom-interest] Some add-ons to JDOM
matt at goxml.com
Mon Feb 12 22:28:11 PST 2001
What you are referring to related to filtering based on the content of an
attribute doesn't (IMHO) belong in the XML Parser. Generally, you would
create a subclass of the parser to handle your specific details.
If the parser *were* to filter based on language, it would probably be
advisable to use the suggested syntax of:
<element xml:lang="SEE_RFC_1766" />
( see http://www.w3.org/TR/2000/REC-xml-20001006#sec-lang-tag for
information on XML's language selection facility. )
Why don't you use XSLT or something like that to do your language selection?
<<| message from: "Joseph Bowbeer" <jozart at csi.com> |>>
Question: Can you explain how the callback mechanism you added is different
> from the XMLFilter that can be applied to the SAXBuilder?
> Suggestion: It would be more efficient to implement your context grouping
> using HashMap instead of Hashtable (no synchs).
> Confusion: I don't follow your comment about testing for root element
> null document, or the subsequent comment about using list operations as
> basis for document maintenance. Can you elaborate?
> ----- original message -----
> From: "de Grijs, Rudolf" <Rudolf.de_Grijs at softwareag.com>
> To: "'jdom-interest at jdom.org'" <jdom-interest at jdom.org>
> Date: Mon, 12 Feb 2001 23:55:20 +0100
> Subject: [jdom-interest] Some add-ons to JDOM
> [ ... ]
> But we found out that a few things were missing with JDOM (version b5):
> First of all we would like to be able to filter the result document. So I
> dived into the source and I was able to implement an efficient callback
> mechanism that's called during the build of the document (using the SAX
> parser). We need this feature since the documents are multi-lingual, e.g.
> <explosion_info language='nl'>....</explosion_info>
> <explosion_info language='en'>....</explosion_info>
> <explosion_info language='fr'>....</explosion_info>
> Well you get the picture. If the customer wants to print a Safety Material
> Data Sheet he must be able to print it in the language of his choice.
> a Filter enables us to filter the result document during the build phase.
> Another wish (which is high on the wishlist I assume) is the ability to
> query the result document with XPath. I had a look at the work done so
> but I was not able to get it working, so I made a fresh (and more
> importantly) and simple start:
> Beside the use of the container (LinkedList) content, which is used to
> the content of an element, I'm using a Hashtable to group the elements
> their context as key. It's just another way of grouping elements according
> to their context. This should make it easier and more efficient to
> Though it's not complete we are using it at the moment to search the
> Safety Material Data Sheet documents. Furthermore I had to make a few
> adjustments to Element, e.g.
> document is not null when an element is part of a document (detecting if a
> Element is the root should be done as follows * (document != null &&
> == null) * instead of * (document != null) *
> Furthermore I don't think it's good practice to allow list operations as
> basis for document maintenance, since you're breaking the implementation.
> E.g. if I want to add different axes using different containers. Within
> methods addContent and removeContent I'm able to synchronize all used
> structures. So as far as I'm concerned they are revived from their
> deprecated status.
> I have never contributed anything to the community so far, so could
> tell me how to proceed (if it's of any use)?
> To control your jdom-interest membership:
interest/youraddr at yourhost.com
<<| end message from "Joseph Bowbeer" <jozart at csi.com> |>>
VP Research & Development, Founder
XML Global Technologies, Inc.
More information about the jdom-interest