Re: [Xswt-developer] the XML parser

[<ha...@id...>]

> -----Original Message-----
> Date: Wed, 28 Jun 2006 22:49:00 -0500
> From: "David J. Orme" <dj...@co...>
> Subject: Re: [Xswt-developer] Design of XSWT: 1) use of XSWTException
> 	and 2) the	XML parser
>
> > Phrased another way: Do we still have to base our design on a one-pass 
> > parsing process?
> >
> Not in my book.  For modules, I think we need some kind of 
> in-memory tree we can use to represent XSWT in an 
> intermediate form.  Naturally, we'll walk that tree as many 
> times as the module is used.  Or the style is used.  Or 
> something like that. :-)

OK, this is similar to how I view it. In the case we stick to a pull parser,
we may build the tree ourselves, but it's far better to (re)use en existing
parser.

> if we can find a way to not need swappable parsing layers,
> I would prefer to not have a swappable XML parser API.

I think understand what you mean. What we could do us define a minimal API
that may be wrapped around an existing parser, so we have something to work
on until we settle on the small one. E.g. we define IMinimumParser, wrap it
around XOM (which is the one I'm familiar with), and rewrite XSWT to use
IMinimumParser. This will let us work on the stylesheet design, without
becoming too parser-specific. When we find our desired parser, we first wrap
it in a IMinimumParser adapter, and if desired we migrate to an interface
fitting that parser better, or to that the parser's native API. The code
using the parser is anyway so local that there's not much work migrating as
long as it is based on an in-memory tree. Of course, this process may be
simplified if we can settle on the parser right away.

Based on my knowledge about how the current parser is used, we need methods
for:

- loading the tree from a URL or InputStream: rootElement =
parser.build(InputStream)
- getting the namespace uri and name of an element:
element.getNamespaceURI() and element.getName()
- getting the child elements of an element: element.getChildElementCount()
and element.getElement(int)
(I don't think the current design requires getting an element's parent)
- getting that attributes of an element, and their name, namespace uri and
value of an attribute:
element.getAttributeCount() and getAttributeName(int),
getAttributeNamespaceURI(int) and getAttributeValue(int)
- getting the text of an element: element.getText()

It wouldn't take much time defining such an experimental interface and wrap
it around XOM. Rewriting XSWT shouldn't be that hard either. Although XSWT's
code is complicated from using a pull parser, the logic is fairly
straight-forward.

Hallvard