Fw: Fw: A weaker XSL?

["Oren Ben-Kiki" <oren@xxxxxxxxxxxxx>]

Paul Prescod <paul@xxxxxxxxxxx> wrote:

>You can be confident that the "buffers" approach was explicitly rejected.
>It is the mechanism used in the most popular transformation tool in the
>SGML world, "omnimark." I think of tree navigation based languages as a
>reaction *against* that.


Like I said, I believe it is too late to raise this issue regardless of any
technical merits. I'm glad to know it was considered and, as usual, would
love to know the details of why this decision was made - I'm a sucker for
'rationale' papers for standards. If I had my way, a rationale would be a
mandatory part of any public standard. Of course, while I'm wishing, I could
also wish for mandatory examples for every BNF term, for free access to ISO
standards, and for winning the lottery, which is more likely then the
previous ones :-)

At any rate:

>How do you express "if my parent's parent's last sibling's 'security'
>attribute is 'top secret' then generate a digital-signature element" or
>more generally "if there exists an element with the following
>characteristics"


First, there's no way to "generate digital-signatures" in XSL :-) But the
question stands. It turns out to be simple to do:

1. Create a "top-secret-list". Populate it with whatever you want to
generate for top-secret documents, regardless of the question whether this
is indeed a top-secret one. Don't worry if the list is invalid for documents
which aren't top-secret.

Then, do one of:

2a. Define a template matching the "top-secret" security level information.
In it, attach the "top-secret-list" to the output tree. If the template
would never match, then the list would be discarded.

2b. Define the same template, but just set a variable to indicate that it
was matched. Then, in a pattern matching the end of the effected part, you'd
generate one of two representations - one using "top-secret-list" and one
which doesn't, depending on the value of this variable.

Yes, I know, this smacks of being an "imperative" solution instead of being
a "declarative" one. As usual, the declarative language might be clearer and
the imperative one is much more efficient and easier to implement :-)

Admittedly, you've paid the price of creating the "top-secret-list" even if
the document wasn't in fact a "top-secret" one. On the other hand, you've
avoided creating a DOM (or something equivalent to it) for the whole input
document. If the input document is 100MB and the "top-secret-list" is 100K,
I know which one I'd prefer.

Also note that the above might hold per fragment of the input tree (lists
can be cleared as well as created), so a 100MB document consisting of 100
1MB sub-documents, each with its own security level, would require creating
and clearing 100 1K "top-secret-lists"; the current approach can't avoid
creating one huge 100MB DOM. I _certainly_ know which scheme I'd prefer in
this case :-)

Share & Enjoy,

    Oren Ben-Kiki


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list