[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: What should TrAX look like? (Was: Re: Article on

• To: xml-dev@l...
• Subject: Re: What should TrAX look like? (Was: Re: Article on JAXP 1.3 "Fast and Easy XML Processing")
• From: Kevin Jones <kjones@s...>
• Date: Sat, 19 Feb 2005 16:21:38 +0000
• Cc: "Michael Kay" <mike@s...>,"'Elliotte Harold'" <elharo@m...>
• In-reply-to: <E1D2Si4-0001QA-00@u...>
• Organization: Sarvega Inc
• References: <E1D2Si4-0001QA-00@u...>
• Reply-to: kjones@s...
• User-agent: KMail/1.6.2

On Saturday 19 February 2005 11:23, Michael Kay wrote:
> > I suspect it would be much cleaner to take an approach
> > like Jaxen's. In
> > this approach there's a core set of basic operations
> > that all model-connectors must implement (getChild,
> > getAttribute, getParent, etc.). However most other axes
> > have default implementations that build
> > on top of the basic operations. For instance, the
> > ancestor axis is easily implemented on top of
> > getParent. Thus a minimal implementation only has to
> > provide about 20 fairly straight-forward operations.
>
> This is similar to the design of Saxon's NodeInfo
> interface, except that in NodeInfo there are no methods
> such as getParent and getChild, instead the provider must
> implement a minimum set of axes: ancestor, child,
> attribute. For other axes, the provider can call on
> helper implementations provided by Saxon.

Both of these sound like nice solutions to the XPath to OM 
interface. What troubles me about them is that if you are 
working outside this scope you are stuck; they assume a lot 
which may not be true of some formats and at the same time 
(I assume) are closed to extension.

I am struck by a similarity here with the security 
standards. As I am sure you know they are large, 
comprehensive and very flexible and as a result fairly 
difficult for the casual user to deploy easily. The 
solution of subsetting common combinations of options as 
pre-packaged solutions for certain domains has made that 
whole problem much more managable during practical 
deployment.

If I view the models you mention in this light I don't see 
them as atomic but compounds made up to meet the needs of a 
particular domain, i.e. XPath. Specifically ones which 
require the features of ancestor navigation, child 
navigation and attribute navigation, but specifically not 
random access navigation. 

The work on alternative ways of implementing XPath, such as 
the BEA XQuery paper, really hightlight that while this 
type of feature set is the commonly required one for an 
XPath implementation it is not the only set that can be 
used. This to me appears to be a fairly universal truth 
about virtually all XML processing algorithms.

Kev.

• Follow-Ups:
  • Re: What should TrAX look like? (Was: Re: Articleon JAXP 1.3 "Fast and Easy XML Processing")
    • From: Elliotte Harold <elharo@m...>

• References:
  • RE: What should TrAX look like? (Was: Re: Article on JAXP 1.3 "Fast and Easy XML Processing")
    • From: "Michael Kay" <mike@s...>

• Prev by Date: RE: Transmitting XML between different applications
• Next by Date: Re: What should TrAX look like? (Was: Re: Articleon JAXP 1.3 "Fast and Easy XML Processing")
• Previous by thread: RE: What should TrAX look like? (Was: Re: Article on JAXP 1.3 "Fast and Easy XML Processing")
• Next by thread: Re: What should TrAX look like? (Was: Re: Articleon JAXP 1.3 "Fast and Easy XML Processing")
• Index(es):
  • Date
  • Thread