RE: XSL equivalent sought.

Subject: RE: XSL equivalent sought.
From: "Didier PH Martin" <martind@xxxxxxxxxxxxx>
Date: Mon, 4 Oct 1999 08:13:50 -0400
Hi Brandon,

Many thanks for your thoughtful message. You brought on the table very
interesting arguments. Thanks for your research, I'll keep that in my
notebook for future reference.

The select-element and match-element would also greatly benefit from a more
elaborate string based expression. The only actual problem with these
construct is that they are restricted to only grove nodes of type "element".
If they could be expanded to reach any grove element, they would, indeed,
become very powerful constructs. So, to have instead, select-node and

Didier PH Martin

Quoting Peter Nilsson <pnidv96@xxxxxxxxxxxxxx>:
> Ok. Where is this discussion going? Some people want a path language (I
> also think it could be useful). I proposed that such a language be
> implementable in DSSSL (not that it has to be implemented in DSSSL).
> However, I don't find it that important that I would spend muh time on it.
> If anyone has some code to show that implements some path language, we
> could check it out and experiment with it. Otherwise, it may be that
> people don't find it critical to have and we could drop the idea.

Quoting Brandon Ibach
   Well, I had hoped to do more with this before I posted it, but I
guess I should speak up now.  DSSSL already *has* a path language, of
sorts, in the form of the match-element? and select-elements
procedures.  Of course, something more powerful, such as XPath, would
be a nice feature to have.
   Toward that end (and in response to Didier's challenge from a
couple of days ago), here's an interesting little thing I put
together.  The document, which contains its own, very simple, DTD,
basically contains a 3x3 "grid" of color names, the rows being marked
A, B and C, and the columns D, E and F.  An attribute of the document
element contains a match-element? pattern which is modified in the
stylesheet to anchor it to the root.
   The document actually gets the value of this attribute from an
entity which get *its* value, via a formal system identifier, from
standard input.  Thus, after starting Jade/OpenJade, you should type
in an A, B or C and a D, E or F, separated by whitespace, then
indicate end of file.  Alternatively, just use "echo" to feed in your
selection.  You will get a report of which color you "chose".
   This, in itself, is not terribly impressive, but it does show the
potential for a string to be parsed into a pattern with which to
select nodes from the grove.  I don't think it would be too difficult
to create functions in DSSSL for parsing and executing XPath
expressions.  We could even create extensions to XPath (which is
allowed by its specification) to generalize it a bit more for use with
non-SGML groves.
   There is nothing that can't be read from a grove with SDQL.  In
fact, a very small subset of SDQL (smaller, even, then the "Core"
query language) provides access to everything in the grove.  All of
the more powerful functions, such as match-element?, are simply built
on top of this subset (or can be, anyway).  XPath, being a
higher-level, declarative language, can be built on top of the more
basic functions in much the same way.

-Brandon :)

 DSSSList info and archive:

Current Thread