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

We need an XPath API

• From: Charles Reitzel <creitzel@m...>
• To: xml-dev@l...
• Date: Sat, 03 Mar 2001 16:29:44 -0500 (EST)

XPath isn't XML, so none of the XML tools work on it.  That said, it appears
that parsing and interpreting XPath expressions is becoming more and more
important in its own right.

Proposal: let's give XPath the SAX treatment.

What should such an API do?  How should it behave?

1) Small, lightweight
2) Should emit/accept XML representation 
   of XPath expression
3) Provide info about expression
4) Define an XML representation of XPath expressions

Possibles (not so small):
1) Provide DOM traversal?
2) Provide SAX-based pattern matching?


Ex.

interface XPathExpr implements Collection
{
   XPathExpr();
   XPathExpr( String xpath );

   boolean isRelative();
   boolean isAbsolute();
   boolean isRelativeDown();

   boolean isElement();     // Points to an element
   boolean isAttribute();   // Points to an attribute

   String toXml();
   void   fromXml( String xmlRepXPath );

   final int XPATH_PART_ELEM_NAME   = 100;
   final int XPATH_PART_ELEM_ORD    = 101;
   final int XPATH_PART_ELEM_RELEX  = 102;
   final int XPATH_PART_ELEM_CURR   = 103;
   final int XPATH_PART_ELEM_PARENT = 103;
   // ...more...

   final int XPATH_PART_ATTR_NAME   = 200;
   final int XPATH_PART_ATTR_ORD    = 201;
   final int XPATH_PART_ATTR_RELEX  = 202;
   // ...more...

   // Need to define granularity of parsing.
   // Probably similar to SAX: support 80% of apps
   // that do not need to maintain exact text.
   interface XPathExprPart
   {
     String part();  // text, sans delimiters
     int    type();  // one of constants above   
   }

   // Iterate over expression parts
   Iterator exprParts();  // Same as iterator
}

interface XPathDOMHelper
{
  XPathDOMHelper( org.w3c.Document doc );

  org.w3c.Node    findNode( XPathExpr xpath );
  org.w3c.Element findElem( XPathExpr xpath );
  org.w3c.Attr    findAttr( XPathExpr xpath );

  // xpathElem identifies Element to update.  Must exist.
  void insertAttr( XPathExpr xpathElem, org.w3c.Attr attr );
  void updateAttr( XPathExpr xpathElem, org.w3c.Attr attr );
  void deleteAttr( XPathExpr xpathElem, org.w3c.Attr attr );

  // xpathElem identifies location of Element in DOM.
  // Parent and referenced siblings must exist.
  void insertElem( org.w3c.Element elem,        // last child
                   XPathExpr xpathParent );
  void insertElem( org.w3c.Element elem, 
                   XPathExpr xpathParent, XPathExpr insertBeforeSib );

  void updateElem( XPathExpr xpathElem, org.w3c.Element elem );
  void deleteElem( XPathExpr xpathElem );

  // ... more ...
}


// Provides same methods as ContentHandler, but w/ an 
// extra XPathExpr argument, which identifies which pattern
// was matched.  An XPathSAXHelper would take the pain
// out of state managment.

interface XPathHandler
{
  // ...
  void startElement( String namespaceURI, String localName, 
                     qName, Attributes atts, XPathExpr xpath );
  // ...
}

interface XPathSAXHelper 
   extends org.xml.sax.helper.XMLFilter
{
  void registerExpr( XPathExpr xpath );
  void setHandler( XPathHandler handler );
}



On Fri, 02 Mar 2001 08:24:43 -0800, Joe English wrote
>Subject: Re: XML Ain't What It Used To Be
>Keith Wedinger wrote:
>
>> Just read this article on XML.com and I have to agree.  The preponderance of
>> new XML specs/standards seems to have turned a relatively simply mark-up
>> language into a full blown, rather complicated software development
>> environment.  But, anyone doing XML development work is certainly not forced
>> to use all of these standards.
>
>Not entirely, but there are some dependencies.
>
>One disconcerting trend is the reliance of XQuery and other
>specs (which I might want to use) on W3C XML Schemas (which
>I do *not* want).
>
>XSLT, XQuery, XPointer, and XLink all rely on XPath.
>Now XPath is a perfect match for XSLT, but IMO it's much
>more powerful than what is needed for the others.  The
>extra power has a price: it makes it harder to implement
>the specs built on top of it.  Sometimes implementors can
>leverage existing work, but not always -- for example,
>you can't just take Saxon's XPath implementation (which
>is one of the best) and plug it into Kweelt (one of the
>more promising XQuery-like implementations); the
>internal data structures are far too different.
>
>
>--Joe English
>
>  jenglish@f...
>

• Follow-Ups:
  • Re: We need an XPath API
    • From: Eric van der Vlist <vdv@d...>
  • Re: We need an XPath API
    • From: "Simon St.Laurent" <simonstl@s...>
  • Re: We need an XPath API
    • From: Robin Berjon <robin@k...>
  • Re: We need an XPath API
    • From: "Thomas B. Passin" <tpassin@h...>
  • re: We need an XPath API
    • From: David Megginson <david@m...>
  • Re: We need an XPath API
    • From: Christian Nentwich <c.nentwich@c...>

• Prev by Date: Re: is that a fork in the road?
• Next by Date: Re: We need an XPath API
• Previous by thread: Re: Give 'em some rope (was [xsl] ANNOUNCE: Petition to withdrawxsl:script from XSLT 1.1)
• Next by thread: Re: We need an XPath API
• Index(es):
  • Date
  • Thread