OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] What should TrAX look like? (Was: Re: [xml-dev] Articleon

[ Lists Home | Date Index | Thread Index ]

Kevin Jones wrote:


> 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.

We are of course talking here primarily about the needs of XPath. This 
is what Source is used for. It certainly isn't good for much of anything 
else. XSLT comes along with XPath because they share the same data model.

Furthermore, most schema languages I can think of don't need any 
information that isn't in the XPath data model. The only real exception 
are DTDs (consider entities), but that support is built into the 
parsers, so we can live without specifically supporting DTD validation.

If we can define an adapter that's strong enough to support XPath 1.0, 
then I've we've got something very useful. Remember, we're not trying to 
define an arbitrary processing model. We just need a least common 
denominator, read-only model that can map between different models and 
XPath engines.

> 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.

I deliberately don't want this to be large or flexible. I want it to be 
small and adaptable. It will not do everything, just what's needed for 
XPath.

> 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.

Could you elaborate on this, or provide a reference? Would the BEA 
implementation be unable to work with a model that provided the basic 
axes we're talking about here?

-- 
Elliotte Rusty Harold  elharo@metalab.unc.edu
XML in a Nutshell 3rd Edition Just Published!
http://www.cafeconleche.org/books/xian3/
http://www.amazon.com/exec/obidos/ISBN=0596007647/cafeaulaitA/ref=nosim




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS