Re: [xml-dev] MicroXPath proposal

[mozer <xmlizer@gmail.com>]

Did I miss something
If the current data model is the one defined at [1]
[[
Data model.  The MicroXML specification should define a single,
normative data model for MicroXML documents. It should be as simple
possible:
* The model for a MicroXML document consists of a single element.
* Comments are not included in the normative data model.
* An element consists of a name, attributes and content.
* A name is a string. It can be split into two parts: a prefix, which
is either empty or ends in a colon, and local name.
* Attributes are a map from names to Unicode strings (sequences of
Unicode code-points).
* Content is an ordered sequence of Unicode code-points and elements.
* An element probably also needs to have a flag saying whether it's an
empty element. This is unfortunate but HTML5 does not treat an empty
element as equivalent to a start-tag immediately followed by an
end-tag: elements like <br> cannot have end-tag, and elements that can
have content such as <a> cannot use the empty element syntax even if
they happen to be empty. (It would be really nice if this could be
fixed in HTML5.)
]]

It means you have also attribute and text nodes

Xmlizer

[1] http://blog.jclark.com/2010/12/microxml.html
On Thu, Jan 13, 2011 at 7:12 AM, John Cowan <johnwcowan@gmail.com> wrote:
>
> I've been thinking a lot about MicroXML, MicroXSD, MicroRNG, etc., and
> I thought I'd take a stab at a MicroXPath.  This is intended to be,
> like the others, the simplest thing that could possibly work.
> However, I'm not a frequent XPath user, so I may have put together
> something that is *too* simple to work.  So I'm posting here for
> comments.  (I'm using this address because xml-dev drops posting from
> my permanent cowan@ccil.org address on the floor, for some reason).
>
> One principle is that since elements are the only kind of node in the
> MicroXPath data model, XPath expressions return only lists of
> elements.  Another is that 100% compatibility with XPath 1.0 isn't
> essential, since most XPath expressions are fairly transient compared
> to XML documents or schemas.
>
> So here's what I've got.  The only kind of expression is a location
> path.  Location paths can be absolute or relative, and their steps can
> be separated by either / or //.  A path step is an element name, star,
> dot, or dot-dot.
>
> Only one predicate is allowed per step, and it has to take one of
> these eight forms:
>
> 1)      a literal number
>
> 2)      last()
>
> 3)      location-path="string"
>
> 4)      @name="string"
>
> 5)      location-path/@name="string"
>
> 6)      @@name="string"
>
> 7)      location-path/@@name="string"
>
> 8)      function(.)
>
> @@ means "inheritable attribute", and is provided for brevity and
> convenience.  In form 8, the function name is provided externally to
> XPath (there are no built-in functions except last()), and accepts the
> current element node and returns a boolean value.  This is the
> programmatic escape from MicroXPath that allows complex predicates.
>
> What's missing?  What can I take out?  Comments solicited.
>
> --
> John Cowan       http://www.ccil.org/~cowan        <cowan@ccil.org>
>       You tollerday donsk?  N.  You tolkatiff scowegian?  Nn.
>       You spigotty anglease?  Nnn.  You phonio saxo?  Nnnn.
>               Clear all so!  `Tis a Jute.... (Finnegans Wake 16.5)
>
> _______________________________________________________________________
>
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>