Le 10 déc. 04, à 13:18, Daniel Fagerstrom a écrit :

...Looks nice to me. I would sugest that you put the xslt with some working examples in the samples directory in the template block. So it becomes easier to experiment with and enhance...

Sure - I was going to wait a bit for feedback though, as this is really not specific to Cocoon, only to XSLT, so maybe some non-committers can collaborate on the wiki before going to SVN.

...I think that puting a name space on the attribute directives is a must. It makes it much easier to see what is code and what is data at a glance. Also it cooperates much better with a strict XHTML scheme...

You're right, we need to namespace the attributes, it's much cleaner.

...I have not tested how it work or read the XSLT in detail, but I wonder about the CSS rules in the style section, will not the XSLT try to expand their bodies? You could use the same escaping as in XSLT attributes:

body {{ font-family: Georgia,sans-serif; }}

No need to do that, the <script> element is copied verbatim when creating the final XSLT. The wiki example works as is.

...   <div class="content">
     <div for-each="//document/body/s1" class="s1">
       <h2>[EMAIL PROTECTED]</h2>

       <!-- This copies paragraphs in the input: -->
       <p for-each="p"
          copy-of=".">
         Example paragraph
       </p>

Is that a rule, or does this mean that all <p> will come before the <table> that is below?

      <table border="1">
         <tr for-each="tr" copy-attributes="@*">...

I think rules are needed, our xdocs are a good use case: they contain some stuff that is already xhtml-compatible, that you only need to copy with small adjustments, as in my example where I add a border on the <table>.

For me, the template author just wants to say "all <table> elements must be copied with border=1 added", but he has no idea in which order the elements will appear in the source, and shouldn't have to care.

Does your for-each syntax allow this? I think it requires declarative rules, and if we're careful about how they are defined, they won't be too scary and will add a lot of power. I've put my rules in a separate div on purpose, to make it clear that the template has a "linear" part and another "rules" section, and that the "rules" section works in a different way than the rest.

WDYT?

-Bertrand

Attachment: smime.p7s
Description: S/MIME cryptographic signature



Reply via email to