RE: XSL equivalent sought.

["Didier PH Martin" <martind@xxxxxxxxxxxxx>]

Hi Peter,

Peter said:
I get somewhat confused. I thought we were talking about DSSSL-2. then,
IMO, it is more interresting if it *can* be implemented in terms of SDQL
rather than how it actually gets implemented (since the standard shouldn't
force implementation details).

Didier says:
I'll start to hate email and the confusion it brings :-) In DSSSL-2, if we
speak of a  way to access GROVE elements based on a string expression like,
for instance, xpath, we no longer talk about SDQL except if SDQL, itself, is
amended to include such expression.

If I understood you well, you suggested a way to implement it with SDQL and
this is a good suggestion.

 > Note: Your point to name the function xpath-location instead of
path
> indicates that the path is xpath. However, we may have here the
opportunity
> to include a bigger set like is done in the second type of construct (see

Peter said:
I think he just picked a name to illustrate what he meant. Ofcourse, the
name of a construct should reflect what the cosntruct is for.

Didier says:
OK guys stop talking for each other :-) Yes I understood Matthias' point and
I just replied that my first name "path" or Matthias suggested name
"xpath-location" coud be better renamed "grove-path".

Peter said:
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.

Didier said:
I do not know. I just stated some interesting results from recent research.
During this research, I discovered that string based expression reduces the
number of constructs. So instead of having several rules like (a) element,
(b) id, (c) query, etc.. all these could potentially be replaced by a single
one using a string based expression to reach any object in a GROVE. This is
just an objective observation. My intention was to at least mention it and
propose some work about this in the scope of work for DSSSL2.

You made the right suggestion by proposing that such string based expression
could be implemented as a function with SDQL. You also mentioned that before
doing anything for DSSSL2 we should first make this implementation on SDQL.
My point is not to say that this is not good but that a string based
expression could be (I said could be) added to DSSSL in a more standard way
(through the specs). This process is independent of any implementation or
trial. Such string based expression could also be beneficial to Hytime by
providing alternative ways to reach GROVE elements. Thus, we would have a
procedural way and a string based expression (or name space) way to reach
GROVE elements. Now, the question could be: Could SDQL be amended to include
a string based expression to reach GROVE elements? We can, at least talk
about it and see if this improvement would be beneficial to any SGML based
language using SDQL (as for example ISMID and Hytime).

Of course, code may be useful for trial. So, for this part, I am always
working on the OpenJade GROVE manager module and try to give it a sound API.
Also, I am slowly finding ways to implement such string based expression
language as a way to access GROVE elements. As you know, OpenJade code is
not always obvious nor easy to work with :-)

In conclusion, Your suggestion to do an implementation as a DSSSL function
for such string based language is an excellent one and thanks for this
thoughtful suggestion. We can, this way, make a small prototype. We'll see
how easy it is to create a parser with DSSSL and discover what are the
actual limits of SDQL. This exercise could help for any debates about SDQL.
>From an other point of view, it not necessary to wait for this experiment to
start working on a DSSSL2 proposal. For this last task, the last 20 years of
experience is sufficient. More specifically, we gained knowledge from
different specifications and experiments either from ISO or W3 work. One of
the discovery we made (and not only in the structured document field) is
that string based expressions could be great tools to access members of a
hierarchical structure. Finally, speaking of implementation, what is
preventing me to do some experiments based on DSSSL constructs is the lack
of support of the "query" construction rule. This is, in fact, the real
showstopper for any implementation that would use a DSSSL function to
implement a path based query. Thus, I guess that the first step is to do
some C++ code and add the query construction rule and this is not a task
done in a single weekend. If this is done, we may discover that this
construct may be the only one (plus the string based expression) sufficient
and necessary to reach any GROVE element (element, attribute, data content,
processing instruction, DTD, etc.). But the whole process involves,
unfortunately, more than just doing an implementation and some code. I means
that a whole community has to learn from other communities and from this
exchange of knowledge improve the existing tools. And this takes efforts and
open minds.

Cheers
Didier PH Martin
mailto:martind@xxxxxxxxxxxxx
http://www.netfolder.com


--
'(#\P . (#\e . (#\t . (#\e . (#\r)))))


 DSSSList info and archive:  http://www.mulberrytech.com/dsssl/dssslist


 DSSSList info and archive:  http://www.mulberrytech.com/dsssl/dssslist