SAX removing elements

Here's a class you can use to load the text file:

import java.io.*;
import java.util.ArrayList;
public class StringList extends ArrayList {
 public StringList(){
  super();
 }
 public StringList(String fileName){
  this();
  String line = null;
  BufferedReader in = null;
  try {
   in = new BufferedReader(new FileReader(fileName));
   while((line = in.readLine()) != null){
    add(line);
   }
  }
  catch(IOException e){
   e.printStackTrace();
  }
  finally {
   try {
    in.close();
   } catch(IOException e) {
    e.printStackTrace();
   }
  }
 }
 public static void main(String[] args){
  if(args.length < 1){
   System.out.println("Usage: java StringList <text file>");
   System.exit(-1);
  }
  StringList sl = new StringList(args[0]);
 }
}

CJ, How did you want to handle known tags that are inside unknown ones? Or will this not occurr?

The approach I was thinking was to have a HashMap that contains the element names that I want to keep.  Anything else I would delete.  This simplifies the schema I will have to create to leverage jaxb.

example:
<response>
  <time>today</time>
  <item>
      <id>1212</id>
      <price>12.12</price>
      <attributes>
         ...
      </attributes>
  <item>
  <newelement>112121212</newelment2>
</response>

Now what I would like to have as my jaxb schema would be this:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
     <xs:element name="response">
          <xs:complexType>
               <xs:all>
                    <xs:element name="Time" type="xs:string"/>
                    <xs:element name="Item">
                    <xs:complexType>
                       <xs:all>
                          <xs:element name="id" type="xs:long"/>
                          <xs:element name="price" type="xs:double"/>
                       </xs:all>
                     </xs:complexType>
                     </xs:element>
               </xs:all>
          </xs:complexType>
     </xs:element>
</xs:schema>

So I would want to keep Time, Item, id, price and drop any other elements (and their children) from the xml before I pass it to jaxb.  So its not even that the xml needs to be handled and thus ignored.  Just stripped/filtered before we pass the xml string or stream along to the jaxb parser.

Does that make sense?  I will try the above code snippets to see if I can tweak them for my needs.

CJ

The code I posted above should do the trick, instead of having the filter wrap another ContentHandler, you'll just need to output the required read elements.
You could implement the validation of which tags where required as a method instead of using an interface if you wanted, was just making it flexible.

>>instead of having the filter wrap another ContentHandler

Can you tell us how your 'no-wrapping approach' is reflected in the following?

>>public MyFilter(ContentHandler wrapped, MyValidator validator)


>>The approach I was thinking was to have a HashMap that contains the element names that I want to keep

I don't think you need a Map implementation. If you did, what would be the key and what would be the value? All you need is to check the presence of an element name in a list, which would be supplied from a text file to save you having to recompile your class(es) if and when (un)required elements change. Using the code above:

StringList elements = new StringList("yourElements.txt");
...
if (elements.contains(currentElement)) {
       // process/don't process
}

The point about filters (and wrapping) is that they are adapter classes - they are a layer of indirection between your parser source and your consumer target. This allows what is going on in the filter to vary independently of the source and target and not to affect the processing logic of either. Your filter should be a loosely coupled as possible to the source and target and you can achieve this by keeping the variants in a text file.

Alternatively you could also write a ContentHandler that outputs the new filtered xml and use that with the filter I supplied above. Depends if you want a more general solution or if you want a class that just performs the  specific task required.

I do need a general solution as several APIs will have different "required" elements

CJ

That would just require a different list of elements to be supplied to whatever was handling the validating of tags.

>>I do need a general solution

The method i mentioned above will give you a flexible, extensible solution

how is the rddl stripper different than what objects posted.  They look very similar to me.  the RDDLStripper seems to be more robust but I would like to know the underlying differences or the "features"

I appreciate both of you guys helping :-)

CJ

What I was thinking is modifying the xml and then the remaining string that remains the filtered xml would be passed into the jaxb parser.

I am not familiar with SAX, I have lived a sheltered life of DOM parsing but my manager seems to believe SAX will be faster, which probably is true.

So please bear with me as I am learning SAX parsing as we go along here :-)

CJ

I guess I am not understanding how the above methods are actually removing elements and then return the remaining xml.

CJ

>>how is the rddl stripper different than what objects posted

You mean 'how is what objects posted different than the rddl stripper'? ;-) Not much - hence my comment above at 12/18/2003 04:17AM PST.

>>I guess I am not understanding ...

What's actually happening is that you use the class in question as a layer of indirection between the sax source and the 'real' content handler. Any content that you want kept gets passed on to the 'real' content handler. Any content that needs to be ignored doesn't.

The significant part of the answer (you can pick up SAXFilter examples with a web seach easily enough) lies in what I was saying about using a declarative approach (your tags in a text file) for maximum flexibility.

What am I supposed to use as the ContentHandler that is passed to the new class that extends ContentHandler?

CJ

I tried:
                  XMLFilter filter =
                        (XMLFilter) Class
                              .forName("org.xml.sax.helpers.XMLFilterImpl")
                              .newInstance();
                  MyFilter myfilter = new MyFilter(filter.getContentHandler());
                  filter.setParent(XMLReaderFactory.createXMLReader());
                  filter.setContentHandler(myfilter);
                  filter.parse("myfile.xml");

but filter.getContentHandler() which I thought would return the default handler returns null.

CJ

>>What am I supposed to use as the ContentHandler that is passed to the new class that extends ContentHandler?

That's meant to be your real ContentHandler. What were you going to do there - i.e. why are you sax parsing in the first place?

yup, I figured that out shortly after the post :-)

quick question, for debugging purposes: how do I output the resulting filtered xml?

after

filter.paser("myfile.xml");

what can I put in to show the resulting xml.

CJ

Nevermind, figured that out too.

Just running some tests now.

CJ

I did something a little different, please let me know if this is not a good approach:

public class CustomXmlFilter extends XMLFilterImpl {

      private String currentElement = null;

      public CustomXmlFilter() {
            super();
      }

      public void startElement(
            String namespaceUri,
            String localName,
            String qualifiedName,
            Attributes attributes)
            throws SAXException {
            this.currentElement = localName;
            AttributesImpl attributesImpl = new AttributesImpl(attributes);
            if ("Time".equalsIgnoreCase(localName)) {
              super.startElement(namespaceUri, localName, qualifiedName, attributesImpl);
            }
      }
      
      public void characters(char[] ch, int start, int length)
            throws SAXException {
            if ("Time".equalsIgnoreCase(this.currentElement)) {
              super.characters(ch, start, length);
            }
      }
      
      public void endElement(String uri, String localName, String qName)
            throws SAXException {

            this.currentElement = null;
            if ("Time".equalsIgnoreCase(localName)) {
              super.endElement(uri, localName, qName);
            }
      }
}

Is this in essence the same?

CJ

>>Is this in essence the same?

Yes. Of course, you wouldn't in reality want to be hard-coding element names like that, but should be using the declarative approach, using an external source for the element names.

yes,  I was just using one elem as a test case.

I am now setting it up to take in a list of strings read in from a config file.

CJ

In essence thats the same, I think my codes a bit more robust and adaptable :)

> how is the rddl stripper different than what objects posted.

Its strips out known tags (not unknown tags) and also leaves the contents of the tag.

Yep, looks OK. Of course in some situations you may need to implement what could be called a 'sax filter pipeline' approach which would be flexibility on a larger scale still and would be something like you get with servlet implementations sometimes. Each filter would have a 'next filter' pointer (or better still an object that would return the next filter pointer) so that each filter could be responsible for doing a different thing then passing it on.

That code won't handles cases like:

<Time>
   <unknown></unknown>
</Time>

   

A SAX approach is inherently non-hierarchical. If you want a hierarchical view of a document then you should go for a DOM approach.

If you need to consider a reasonably trivial hierarchy, then you can push elements on stacks before making processing decisions.

> A SAX approach is inherently non-hierarchical.

Yes, but XML documents aren't.

The code I posted earlier handles "trivial hierarchy" just fine :)

Nobody's mentioned needing *any* hierarchy as far as i can see.

So what exactly are you arguing here. Are you saying that a solution that simply stips start and end tags with unknown names is better than one that handles possible nesting of tags?

What i'm saying is the following

a. so far the only person who's mentioned hierarchical considerations is yourself
b. if there *were* hierarchical considerations then that way of approaching it would not be reusable. A better way would probably be to do a transform. The declarative configurability would then be not in a text file, but in an xsl file.

CEHJ> What i'm saying is the following

Seems to me you're just being argumentative for no particular reason. CJ asked about differences and I was answering him. I'm really not interested in a pointless debate with you about it.

cheekycj> I am now setting it up to take in a list of strings read in from a config file.

From what you've said a Set would be more suitable.

The APIs are trivial hierarchies (from what I see in the returned xml)

As far as reading the elements from a config file.  We have a xml based config file framework already setup so I just have to tell the owner of that part to add my required elements.  There is a standard mechanism for retrieving config params.  I will have probably have a hashmap or a list representing the required elements of an API.

are you guys contending that extending XMLFilterImpl and doing it that way is not robust for hierarchies?

CJ

> I will have probably have a hashmap
> or a list representing the required elements of an API.

Wouldn't a Set be more suitable?

> are you guys contending that extending XMLFilterImpl
> and doing it that way is not robust for hierarchies?

I'm not contending anything really, just pointing out possible cases you may need to account for depending on your requirements.

>>are you guys contending that ...doing it that way is not robust for hierarchies

I think you'd probably be better off with a transform, the purpose of which, after all, is to transform one hierarchy into another.

objects: why would a set be more suitable?  Doesn't a HashMap perform the same as a HashSet as far as lookups, or would some other collection perform better?  Is HashMap.containsKey slower than HashSet.contains().  I guess, Maps are just a norm at my company so I was thinking of using that.  Its not written in stone :-)

CEHJ: I wanted to go with a transform initially but time constraints and the lack of knowledge on how to do that, made us decide against it.  Time to market wins over any robust solution these days :-(

CJ

Sets are appropriate when no duplicates are involved so in a flat hierarchy you may as well use a Set over a List, since no duplicate  element names would be involved.

>>Time to market wins ...

Well, since there are plenty of transform examples available and the tools to use them, i would have thought it would be quicker to use them than reinvent the wheel...

Here's one example right off:

http://javaalmanac.com/egs/javax.xml.transform/BasicXsl.html

Your requirement is simpler still in concept: if you want elements to be ignored, all you have to do is to ensure that there are no matching templates for those elements in the xsl

> Doesn't a HashMap perform the same as a HashSet as far as lookups, or would
> some other collection perform better?

Yes but the use of a Map is redundant, as you don't have jey, value pairs.

The filter is working so far so I think I am going to stick with it.

If I find time later, I might refactor it to use xsl.

I will award the pts shortly - prbly a split if you guys don't mind.

CJ

Sorry for the delay guys, took a unexpected 2 week leave from work - new baby boy :-)

I am splitting the pts (and upping them) for your great work and assistance.

Cheers,
CJ

> new baby boy :-)

Congatulations, hope mother and baby are both well.

We're also expecting a new addition in the next couple of months :)

8-)