Re: MicroXPath proposal

My two satang's worth on this is that XPath 1.0 is already fairly micro.  For me (and I am admittedly biased) the natural MicroXPath is XPath 1.0, with its namespace treatment adjusted to be consistent with whatever MicroXML does.  For example, if MicroXML takes the approach of allowing prefixes but not giving any special meaning to namespace declarations, then MicroXPath would just match prefixes and treat namespace declarations as attributes.  In fact, since XPath 1.0 is defined in terms of its data model, this adjustment can (all/mostly?) be handled by specifying an appropriate mapping from the MicroXML data model to the XPath 1.0 data model, without changing the semantics of XPath 1.0 itself.

XPath 1.0 isn't hard to implement; the challenge is more in making it efficient.  I would guess the most inconvenient part is the namespace axis, and adjusting MicroXPath to match the MicroXML treatment of namespaces would hopefully get rid of that.

XPath 1.0 can already express inherited attributes; it would be nice to have a simpler way of doing this, but once you open the door to extensions, it's hard to know where to draw the line.

The only subset of XPath 1.0 that makes sense to me is one that has the goal of being able to create one path that uniquely identifies any element (and perhaps attribute) in a document. Something like

  /foo[2]/bar[1]/baz[3]

But this subset would useful in only a small subset of the cases in which XPath 1.0 is useful.