Inline XSLT instructions?

[Evan Lenz]

Before I forget, I did want to put one idea out there. I had done some more thinking about the concerns that Michael Kay brought up around parsing difficulties when adding functionality to languages like XQuery or Carrot. XSLT has it easy in this regard, because all it has to do is add new element and attribute names. What XSLT lacks in composability it partially makes up for in extensibility.

Maybe Carrot can add functionality (like grouping and multiple output documents) using inline XSLT instructions, rather than trying to extend the grammar in some other way. Basically, the XSLT instructions would look like element constructors to the parser, but would be interpreted differently by the compiler. The biggest challenge I see here is handling attributes that contain expressions.

The attributes that contain attribute value templates (AVTs, delimited by curly braces) are not the problem. This, for example, should be fine:

<xsl:result-document href="{any-expression}">

because the Carrot parser would already support the same syntax (normally an element constructor):

<foo bar="{any-expression}">

On the other hand, the ones that require the value to be an expression (not an AVT) raise some questions:

<xsl:for-each-group select="expression" …>

Should the select expression's value be restricted to a subset of Carrot syntax, like it is in XSLT/XPath 2.0? Or can the quotes somehow act like curly braces in enclosing an arbitrarily complex expression?

I'm curious what you guys think of the general idea of supporting inline XSLT instructions (maybe just a small subset of useful ones), and how you might address the questions this would raise.

Evan

[David Lee]

My opinion is that what I see the value of Carrot is that it is NOT using XML as a language syntax.

I fully understand the value of a xml syntax for a language but that value is primarily for the language developer not the user

(with the exceptional case of computer generating code ).

 

I’m willing to accept that its harder to extend a ‘natural language’ then an XML language and in fact may lead to ambiguities or simply some weird syntax occasionally.

But if were going to start to allow XML syntax in Carrot then why not just use XSLT …

 

Unless a goal is a “Polyglot” language where both XQuery and XSLT can be intermixed.

But what I loved about Carrot was that we could get the (most) of functionality of XSLT AND XQuery while sticking to a non-XML syntax, in fact one that is even cleaner the XQuery itself.

 

But maybe there are exceptions. 

For example I’ve gotten to accept the annotation syntax in Java as sort of an ‘out of band’ language which is supplementary but not core.

Maybe something like that for Carrot.  But using XML syntax instead of Java’s @annotaiton syntax.

Like say

 

<xslt:extension/>

Foo() := bar()

 

Applies an xslt extension to the following expression …

 

(bad example but I cant think of a good one sorry … its late …)

 

Brings up an interesting question … should this be part of the language or the XDM Output ?

Thinking about Han’s (and mine) presentation at Balisage about XDM Markup.

Maybe *post processing* is a way to handle this … output XDM which Is marked up by syntax which provides additional features.

Clearly that doesn’t solve all problems.

 

Maybe a list of what kinds of XSLT features we’d want to treat and how to encode them in the grammer ?

I’d personally rather not see Carrot become a polyglot language because I think it will become too hard to make it clean … it will quickly become the union of XQuery and XSLT

 

 

 

----------------------------------------

David A. Lee

dl...@calldei.com

http://www.xmlsh.org

[Eric Bloch]

I agree strongly with David's first paragraph and opinion. Choosing XML as programming language syntax is widely viewed (outside of the XSLT community) as a bad choice for the user writing code in that language.

________________________________________

[Florent Georges]

On 8 September 2011 15:53, Eric Bloch wrote:

> Choosing XML as programming language syntax is widely viewed
> (outside of the XSLT community) as a bad choice for the user
> writing code in that language.

I am definitely in the XSLT community, then ;-)

Cheers,

--
Florent Georges
http://fgeorges.org/
http://h2oconsulting.be/

[Evan Lenz]

Point taken! Then we should probably put certain items on the syntax/language definition TODO list (and prioritize them), including:

• xsl:result-document
• xsl:for-each-group
• xsl:analyze-string
• …

Or punt and just say you have to import XSLT if you want to do these (or certain ones among these). My thought was that it would be nicer to support them inline rather than forcing the user to import external code. But I don't want this Carrot to become any less appetizing to its valuable community members! ;-)

Evan

[David Lee]

I would vote that the ideal target audience are the 'other' camp like me ... Otherwhy not just use xslt natively

Sent from my iPhone

[David Lee]

Curious what is the goal for the compiled target language?

Sent from my iPad (excuse the terseness)
David A Lee
dl...@calldei.com

[Evan Lenz]

To me, Carrot is about making a more composable and more concise version
of XSLT. It does that by borrowing some syntax and semantics from XQuery
and by inventing some of its own. Multiple implementation approaches are
possible, but perhaps the "canonical" one is compilation to XSLT 2.0. I
also got positive feedback at Balisage about the ability to compile to
XSLT 2.0 (which means there's no lock-in to Carrot, and you can use XSLT
2.0 tools, etc.)

I'm not sure I completely understand your question, but I'd add that, to
fully achieve the goal I had in mind, none of XSLT's powers should be
absent from Carrot (including grouping, regular expression support, and
multiple output documents). These features, then, would compile to
<xsl:for-each-group>, <xsl:analyze-string>, and <xsl:result-document>,
respectively.

Note also that my idea for inline XSLT instructions is that they would be
limited to a very small number of them (not just any old XSLT instruction).

As I wrote in the paper, an alternative would be to wait for grouping
functionality to come along in XQuery 3.0 and use that syntax. But my
guess is that there will still be functionality that's missing in
comparison to XSLT 2.0 (or indeed XSLT 3.0). But maybe that's okay.

That said, in the mean time, one could an import XSLT module from Carrot
to get grouping functionality (just as in MarkLogic you can call out to
XSLT from XQuery when you need grouping), so this probably should not be
top priority. One exception, I think, is getting multiple result documents
working. I'd like to see us get that working, because, it's a lot more
awkward to call out to a different language for those, since they tend to
be more tightly interweaved in one's code.

Evan (excuse the verbosity ;-)

>> <xsl:for-each-group select="expression" Š>

[Evan Lenz]

If we tried to take an 80/20 approach here, my opinions on where each
stand:

xsl:result-document probably in the 80.
xsl:for-each-group (or a subset) maybe in the 80, maybe not.
xsl:analyze-string is out.

And I haven't looked at what other XSLT features I might be overlooking.
(Since they haven't come to mind yet, I'm guessing they wouldn't make the
cut either.) Hmm, there's numbering, which is essential for, say, Docbook
processing and stuff like that...but then a library could probably suffice
for that.

I do like the idea of keeping Carrot small. The question for the future is
whether it becomes XSLT-lite or more like XSLT-inspired (taking on a life
of its own beyond XSLT, with native implementations, etc.)

I can think of a few audiences:

* XSLT users
* XQuery users
* XML users who don't use XSLT (maybe even Web developers at some point...)

So it's partly a question of which audience (or potential audience) we
want to focus on.

Evan

[David Lee]

Why I asked about the expected target generation language is if we want to
support features not natively supported in that target (call it the "virtual
machine bytecode") then were SOL ... or have to resort to vendor specific
extensions.

Group By expressions may (probably?) be translated to XQuery although
inefficiently.
Multiput output streams cannot be done at all in xquery without an extension
function.

So if what you have in mind is ultimately generating XSLT then adding
xslt-compatible features makes sense.
If you intend on generating xquery or xqueryx then we need to be pragmatic
and decide what features are actually implementable, and on what vendors,
even if we can decide on a syntax.

----------------------------------------
David A. Lee
dl...@calldei.com
http://www.xmlsh.org

-----Original Message-----
From: carro...@googlegroups.com [mailto:carro...@googlegroups.com] On
Behalf Of Evan Lenz

[Evan Lenz]

I like the idea of supporting XQuery as a target language too, so maybe
grouping is out for now. I wouldn't be opposed to utilizing
vendor-specific extensions. For example, if Carrot can import/include both
XSLT and XQuery modules, which was an intention, then it will already need
to utilize vendor-specific extensions, e.g., xdmp:import-module or
saxon:import-query. The suggestion in the paper is that the import
semantics in these cases would be dependent on the underlying XSLT
implementation's extension semantics. A pragmatic approach to multiple
output documents would be to look at the XQuery implementations we want to
support, what their extensions support, and go from there.

Next question is how implementation-dependent we allow Carrot to be. I'm
inclined to favor utility over interoperability to a certain degree...
Multiple output documents are somewhat inherently
implementation-dependent, but we can at least use a single syntax at the
Carrot level (as XSLT does with <xsl:result-document>).

Evan