The problem with XSLT, XQuery and others is that they're tranformation languages -- that is, they take XML as input and produce something else, which might indeed again be XML, but can also be plain text, or something more complex. Instead of a tranformation, what the xmld20 project needed, and what Xscr will attempt to provide, is instead a language that modifies a base of XML data.
Since Xscr is being written in XSLT, we must work within its framework, meaning that we can still only really do transformations on the XML data. Instead of a language that expects to be told how to process each of the bits of data, Xscr will, in a sense, have a default action to copy the existing data if an instruction doesn't affect it.
For example, if we have a block such as
<xml> <one/> <two a="b" c="d"/> <three four="five">six</three> <seven> <eight/> <nine ten="11"/> </seven> </xml>XSLT expects to have templates that describe what to do with the xml element, the one element, etc. Yes, you can have defaults that will copy an element if it is otherwise not explicitly processed, and this is what Xscr will have. But what about the changes you might want to make? They can be summarized as additions, deletions and modifications. Sometimes these changes are unconditional, but sometimes they can be conditional. The content of the addition, or modification might be static, or might be variable.
For instance, if we wanted to add an element such as
<ten>eleven</ten>using XSLT... well, it's just not something XSLT does. The best we can do is to have something like
<xsl:template match="xml"> <apply-templates/> <ten>eleven</ten> </xsl:template>With Xscr, we will have something like
<xscr:insert name="ten">eleven</Add>Deletion of the two element in XSLT can be done in a few ways, such as
<xsl:template match="two[a='b' and c='d']"/>the difference of which we'll come back to. In Xscr, we would have
<xscr:delete><two a="b" c="d"/></xscr:delete>or
<xscr:delete xpath="two[a='b' and c='d']"/>And how about changing an element, such as three, where we might change the content in XSLT:
<xsl:template match="three"> <three> <xsl:copy-of select="@*"/> <xsl:text>sixty</xsl:text> </three> </xsl:template>or an attribute:
<xsl:template match="three"> <three> <xsl:copy-of select="@*[name()!='four']"/> <xsl:attribute name="four">fifty</xsl:attribute> <xsl:copy-of select="text()"/> </three> </xsl:template>And in Xscr:
<xscr:setattribute xpath="three[@four='five']" attribute="four">fifty</xscr:setattribute>In general, the Xscr solutions are smaller, but is that any reason to create a different scripting language? No, but here is the biggest problem: using XSLT to match a general or specific is not a problem, but it does require the <xsl:template match=""> element, and - and this is the important bit - it can only be declared once. While we might have a rule that matches all of the "a" elements, and another that matches the "a" elements with certain "b" attributes, we can't have two that both match "a" elements with certain "b" attributes and hope for them both the evaluate. To have two different actions on this same match, both actions must be written in the same element definition. And herein lies the biggest problem with XSLT: to have more than one action based on the same criterion, we must know it ahead of time and write it all at the same time. With Xscr, we can write multiple commands to act upon the same set of data, and better yet, these commands might exist in different files. This is a large requirement for the xmld20 project, and the need for this scripting language.