Subject: Fw: Fw: A weaker XSL? From: "Oren Ben-Kiki" <oren@xxxxxxxxxxxxx> Date: Sat, 6 Feb 1999 20:13:29 +0200 |
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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: Fw: A weaker XSL?, Paul Prescod | Thread | Defeating the MS patent on styles, David LeBlanc |
Venting, Scott Ferguson | Date | Defeating the MS patent on styles, David LeBlanc |
Month |