patch to make debian package, problems
"Magosányi, Árpád"
Unfortunately slaxproc chokes for me even on the example script on
http://www.libslax.org/
And here is a working xslt which shows that we might be in trouble even
with the language spec.
As far as I see, there is a problem applying the "do one thing but do it
right" principle.
The xslt <->slax transformer should not do anything else but transform
between the two languages.
I believe it is easy to define a tremendously slax-like language in a
way that it maps unambigously to xslt.
Running slax is an entirely different thing than converting between
languages.
I do believe that the right architecture for it is to have a parser
which converts the slax to DOM, and pass it to an existing xslt engine.
This parser need not and should not know anything about the xslt and
especially xpath features supported by the engine beyond what is needed
for the syntactic sugar:
This basically boils down to the "default" attributes of certain xslt
constructs (test or select), the xsl:choose <-> if conversion, and maybe
some other things, but xpath is too powerful and complicated to do
anything but copy the expression over.
Adding xpath extensions as part of the language is definitely a bad
idea. If one wants to add xpath functions, one should add them to the
xslt engine. They have nothing to do with the parser part. And anyway,
if you want to do real xslt processing, you would need a 2.0 aware
engine, where implementing xpath functions in xslt is not too
complicated. But the current architecture seems to make the change of
xslt engine painful. This could mean the end of this beautiful project
when everyone starts to talk 2.0.
And here is a patch with which I could successfully make a debian
package on Oneiric. There are a lot of lintian warnings though, the most
problematic is that the extension libraries turned up in a wrong place.
I am neither an automake guru. but I believe it is useable as a starting
point.
On sid the code does not compile because -Werror and unused variables.
Philip Silva
But have you been able to get an example running? If not, I can help you with creating a minimal working example. Some time ago I played a lot with it...
"Magosányi, Árpád"
The things I do are very hard/impossible to do with xslt 1.0. What I need is not to learn the slax language: it should have been a one-to-one map to xlst, so if one knows one of them and the transformation rules, one knows both.
I would like to spare writing the unnecessarily long and complicated xml constructs of xslt, so I wont' have cobol fingers.
If you could show me how to convert the xslt attached in my last mail to slax, I would appreciate it. But first I'm afraid it is impossible as of now, and second it should have been a matter of running slaxproc on it.
Phil Shafer
> <unescape.xslt>
Looks like the web site trashed my example script. I'll repair it, but the real example is here:
http://code.google.com/p/libslax/wiki/SLAXExample
SLAX is attached with XSLT-1 and doesn't support XSLT-2.0. We're using libxslt and there is little chance that this library will ever support 2.0.
Copying XPath expressions is not sufficient, since I need to rewrite them into SLAX primitives, including string escaping, "==", concat(), etc.
Thanks,
Phil
Phil Shafer
If you could show me how to convert the xslt attached in my last mail to slax, I would appreciate it. But first I'm afraid it is impossible as of now, and second it should have been a matter of running slaxproc on it.
"Magosányi, Árpád"
> SLAX is attached with XSLT-1 and doesn't support XSLT-2.0. We're using
> libxslt and there is little chance that this library will ever support
> 2.0. Copying XPath expressions is not sufficient, since I need to
> rewrite them into SLAX primitives, including string escaping, "==",
> concat(), etc. Thanks, Phil
The question is whether you want to rethink the language definition so
it won't go down with the eventual demise of xslt 1.0.
Now libslax mixes at least three things: dom, xpath and xpath functions
(most of which are unnecessary with xpath/xslt 2.0).
I believe that the whole thing could be much cleaner if it would be
reengineered to have three layers. Maybe it could be possible to do in a
way that is backward-compatible, and I think it would definitely be a
smaller and neater code.
A. dom layer. It could be much simpler than now.
The construct
localname(var1=val1,var2=val3){inside stuff}
could be turned to
<localname var1="val1" var2="val3">inside stuff</localname>
with the following rules:
0. An attribute value should never have a single '=', or ',': They have
to be escaped either by doubling or with '\'. '(' should always have its
pair or be escaped by '\'.
1. an unnamed attribute receives the name attrN, where N is its index.
2. if no attributes, the '()' can be left off
3. if inside stuff is empty, then the tag is self closing, e.g. "br{}"
becomes <br/>
4. the rules above result in a correct DOM. Now some simple additional
xslt rules could be applied, so
- special localnames and their first attribute could be transformed.
e.g the dom if(name==$name){stuff} would become the dom
xsl:if(test=name==$name){stuff}
- things like the ifthenelseif -> xsl:choose transition would be possible.
There are two things to note with this approach:
- Using '=' and ',' as the left and right separators for attribute
values have already opened a little can of worms, but this is the
backward compatible way.
- The rules at 4. could be defined to be an open set. The replaced
local names and the name of the default attributes could be defined with
a simple dom and read at runtime. This way upgrades to language syntax
and slax syntax for local namespaces could be easily defined. Do not
forget that we are talking just about the dom, and there is nothing xslt
specific here yet. Even this language definition could become a language
construct, e.g. we could define that after applying rules 1-3, a
predefined set of rules are applied to the dom (in the default
configuration implementing step 4.), and for each slax:transform tag, it
is removed from the dom and its following sibling nodes are subject to
the xslt transformation defined by it. It means that the default
transformation would depend on the xslt processor used. However as you
now plan to use only one xslt processor, it should not be a problem.
B. xpath layer
Well, there are transformations on xpath now, so to preserve backward
compability it is necessary to implement some.
However it would be silly to apply the transformations to every
attribute. They could also be handled by slax:transform.
C. xpath extension functions
They are an entirely different piece of cake. They should be packaged
separately and libslax would depend on them iff it uses its current xslt
processor.
So at the end of the day, slax could be a much neater and powerful tool.
If you choose to take this path, I am willing to write the xslt rules.
Phil Shafer
> The question is whether you want to rethink the language definition so
> it won't go down with the eventual demise of xslt 1.0.
I see it the other way; when/if 2.0 moves along, SLAX will be as compatible with it as XSLT-1.0 is. We can expand the rules without breaking existing code.
> A. dom layer. It could be much simpler than now.
> The construct
> localname(var1=val1,var2=val3){inside stuff}
The current syntax would use:
<localname var="val1" var2="val2" var3="val3> inside-expression;
which is a more direct mapping to XML/XSLT. The "<>" on content is not something I'm out to avoid and allows a simple parsing of content .vs. statements. "sort name" and "<sort> name" are distinct.
> - Using '=' and ',' as the left and right separators for attribute
> values have already opened a little can of worms, but this is the
> backward compatible way.
The current syntax handles this in an unambiguous way.
> They are an entirely different piece of cake. They should be packaged
> separately and libslax would depend on them iff it uses its current xslt
> processor.
This was a difficult decision, but at the end of the day, there were "must haves" that required extension functions and elements.
I need to go look at the xslt-2.0/xpath-2.0 specs and confirm that I've not done anything to preclude moving to support them in the future, but for the mean time, staying with 1.0 seems the better decision.
Thanks,
Phil
"Magosányi, Árpád"
> On Mar 9, 2012, at 2:40 PM, Magosányi, Árpád wrote:
>> The question is whether you want to rethink the language definition so
>> it won't go down with the eventual demise of xslt 1.0.
> I see it the other way; when/if 2.0 moves along, SLAX will be as compatible with it as XSLT-1.0 is. We can expand the rules without breaking existing code.
I would think that having a design which have built-in support for any
later version is a much better approach.
>
>> A. dom layer. It could be much simpler than now.
>> The construct
>> localname(var1=val1,var2=val3){inside stuff}
> The current syntax would use:
>
> <localname var="val1" var2="val2" var3="val3> inside-expression;
No: if, template, match and other construct do not follow this convention.
>
> which is a more direct mapping to XML/XSLT. The "<>" on content is not something I'm out to avoid and allows a simple parsing of content .vs. statements. "sort name" and "<sort> name" are distinct.
>
>> - Using '=' and ',' as the left and right separators for attribute
>> values have already opened a little can of worms, but this is the
>> backward compatible way.
> The current syntax handles this in an unambiguous way.
Just chokes on constructs it should not have touched in the first place.
>
>> They are an entirely different piece of cake. They should be packaged
>> separately and libslax would depend on them iff it uses its current xslt
>> processor.
> This was a difficult decision, but at the end of the day, there were "must haves" that required extension functions and elements.
I don't challenge that they are needed (most of them are not with a
decent xslt engine, but it is not the point). They just should not be in
this package.
>
> I need to go look at the xslt-2.0/xpath-2.0 specs and confirm that I've not done anything to preclude moving to support them in the future, but for the mean time, staying with 1.0 seems the better decision.
1.0 is largely unacceptable for me. I would rather get cobol fingers
than to use it again.
Think a bit about how much your current code, and how much code would be
the solution I have proposed.