[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
We need an XPath API
- From: Charles Reitzel <firstname.lastname@example.org>
- To: email@example.com
- 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?
interface XPathExpr implements Collection
XPathExpr( String xpath );
boolean isElement(); // Points to an element
boolean isAttribute(); // Points to an attribute
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;
final int XPATH_PART_ATTR_NAME = 200;
final int XPATH_PART_ATTR_ORD = 201;
final int XPATH_PART_ATTR_RELEX = 202;
// Need to define granularity of parsing.
// Probably similar to SAX: support 80% of apps
// that do not need to maintain exact text.
String part(); // text, sans delimiters
int type(); // one of constants above
// Iterate over expression parts
Iterator exprParts(); // Same as iterator
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.
void startElement( String namespaceURI, String localName,
qName, Attributes atts, XPathExpr xpath );
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.