Some XSLT hacks for xmlspec documents

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Some XSLT hacks for xmlspec documents

Thomas Roessler

Hello,

I thought it might be time to share some XSLT hacks that I've been
using with xmlspec.

- http://www.w3.org/2006/WSC/drafts/rec/bibsort.xsl

  Sort the blist alphabetically, by key.

- http://www.w3.org/2006/WSC/drafts/rec/fix-style.xsl

  * Some additional style information, to make anchor names visible
    upon hover; stolen from Mark Nottingham's Web site.
  * Adding navigation links (inpsired by Norm Walsh's blog post
    about the XProc drafts; I didn't see him link to any code)
  * Mark broken specprod references (which end up as an <a
    href="#">...) in nasty red.
  * Turn headings into links to themselves, to make copy & paste of
    anchors easier.
  * Different mark-up and formatting for "<note>" elements.
  * <phrase role="sqbrackets"> in xmlspec now causes optically
    highlighted square brackets in the spec text; useful for
    contentious material

Hope these are useful.

Regards,
--
Thomas Roessler, W3C  <[hidden email]>

Reply | Threaded
Open this post in threaded view
|

RE: Some XSLT hacks for xmlspec documents

Jo Rabin-2



That rings some bells:

I'm working on four xmlspec docs in parallel at the moment and this
started to do my head in, rather rapidly. Since it seems that any
document needs a slight tweak to the "standard" XSLT to allow you to do
what you want.

As a result, I did a couple of edits to try to rationalise this, and
have a single XSLT and not have to do any post-processing of HTML.

The first edit is to allow the linking of an additional CSS file. The
current xslt allows you to pass literal CSS as a paramter, but that
didn't really help much.

I'd have much preferred to provide for the literal inclusion of CSS from
an additional file but haven't figured out how to do this simply
[document(), no; unparsed-text(), no; xinclude, needs two passes ...].

The second edit is to include an additional xsl file to allow for
over-riding aspects of the default template's behavior.

I made a couple of other fixes to the standard XSLT but the one that
probably needs doing the most that I haven't done is that a list inside
a paragraph in xmlspec generates invalid XHTML. It's easy enough to
avoid, which is why I haven't fixed it.

For completeness, other tweaks are:
- make the revisiondesc actually generate something
- make the subtitle actually generate something
- make editor's drafts use the editors draft CSS
- provide for mouse-over pop-ups on <kw>s
- include the value of the role attribute on emph elements as a class=
in the output
- change the behaviour of termdef
- make editors notes behave differently
...

Oh and also a separate uprev.xsl to update the date, current and
previous links when preparing a new editor's draft.

Hope of some interest.

Jo




> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On
Behalf

> Of Thomas Roessler
> Sent: 24 October 2007 19:01
> To: [hidden email]
> Subject: Some XSLT hacks for xmlspec documents
>
>
> Hello,
>
> I thought it might be time to share some XSLT hacks that I've been
> using with xmlspec.
>
> - http://www.w3.org/2006/WSC/drafts/rec/bibsort.xsl
>
>   Sort the blist alphabetically, by key.
>
> - http://www.w3.org/2006/WSC/drafts/rec/fix-style.xsl
>
>   * Some additional style information, to make anchor names visible
>     upon hover; stolen from Mark Nottingham's Web site.
>   * Adding navigation links (inpsired by Norm Walsh's blog post
>     about the XProc drafts; I didn't see him link to any code)
>   * Mark broken specprod references (which end up as an <a
>     href="#">...) in nasty red.
>   * Turn headings into links to themselves, to make copy & paste of
>     anchors easier.
>   * Different mark-up and formatting for "<note>" elements.
>   * <phrase role="sqbrackets"> in xmlspec now causes optically
>     highlighted square brackets in the spec text; useful for
>     contentious material
>
> Hope these are useful.
>
> Regards,
> --
> Thomas Roessler, W3C  <[hidden email]>


Reply | Threaded
Open this post in threaded view
|

Re: Some XSLT hacks for xmlspec documents

Thomas Roessler

Sounds interesting, in particular the uprev.xsl.  Where are these
scripts availble?
--
Thomas Roessler, W3C  <[hidden email]>  +33-4-89063488






On 2007-10-24 19:40:33 +0100, Jo Rabin wrote:

> From: Jo Rabin <[hidden email]>
> To: Thomas Roessler <[hidden email]>, [hidden email]
> Date: Wed, 24 Oct 2007 19:40:33 +0100
> Subject: RE: Some XSLT hacks for xmlspec documents
> X-Spam-Level:
> X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.1.5
>
>
>
> That rings some bells:
>
> I'm working on four xmlspec docs in parallel at the moment and this
> started to do my head in, rather rapidly. Since it seems that any
> document needs a slight tweak to the "standard" XSLT to allow you to do
> what you want.
>
> As a result, I did a couple of edits to try to rationalise this, and
> have a single XSLT and not have to do any post-processing of HTML.
>
> The first edit is to allow the linking of an additional CSS file. The
> current xslt allows you to pass literal CSS as a paramter, but that
> didn't really help much.
>
> I'd have much preferred to provide for the literal inclusion of CSS from
> an additional file but haven't figured out how to do this simply
> [document(), no; unparsed-text(), no; xinclude, needs two passes ...].
>
> The second edit is to include an additional xsl file to allow for
> over-riding aspects of the default template's behavior.
>
> I made a couple of other fixes to the standard XSLT but the one that
> probably needs doing the most that I haven't done is that a list inside
> a paragraph in xmlspec generates invalid XHTML. It's easy enough to
> avoid, which is why I haven't fixed it.
>
> For completeness, other tweaks are:
> - make the revisiondesc actually generate something
> - make the subtitle actually generate something
> - make editor's drafts use the editors draft CSS
> - provide for mouse-over pop-ups on <kw>s
> - include the value of the role attribute on emph elements as a class=
> in the output
> - change the behaviour of termdef
> - make editors notes behave differently
> ...
>
> Oh and also a separate uprev.xsl to update the date, current and
> previous links when preparing a new editor's draft.
>
> Hope of some interest.
>
> Jo
>
>
>
>
> > -----Original Message-----
> > From: [hidden email] [mailto:[hidden email]] On
> Behalf
> > Of Thomas Roessler
> > Sent: 24 October 2007 19:01
> > To: [hidden email]
> > Subject: Some XSLT hacks for xmlspec documents
> >
> >
> > Hello,
> >
> > I thought it might be time to share some XSLT hacks that I've been
> > using with xmlspec.
> >
> > - http://www.w3.org/2006/WSC/drafts/rec/bibsort.xsl
> >
> >   Sort the blist alphabetically, by key.
> >
> > - http://www.w3.org/2006/WSC/drafts/rec/fix-style.xsl
> >
> >   * Some additional style information, to make anchor names visible
> >     upon hover; stolen from Mark Nottingham's Web site.
> >   * Adding navigation links (inpsired by Norm Walsh's blog post
> >     about the XProc drafts; I didn't see him link to any code)
> >   * Mark broken specprod references (which end up as an <a
> >     href="#">...) in nasty red.
> >   * Turn headings into links to themselves, to make copy & paste of
> >     anchors easier.
> >   * Different mark-up and formatting for "<note>" elements.
> >   * <phrase role="sqbrackets"> in xmlspec now causes optically
> >     highlighted square brackets in the spec text; useful for
> >     contentious material
> >
> > Hope these are useful.
> >
> > Regards,
> > --
> > Thomas Roessler, W3C  <[hidden email]>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Some XSLT hacks for xmlspec documents

David Carlisle
In reply to this post by Jo Rabin-2


> I made a couple of other fixes to the standard XSLT but the one that
> probably needs doing the most that I haven't done is that a list inside
> a paragraph in xmlspec generates invalid XHTML. It's easy enough to
> avoid, which is why I haven't fixed it.

The version of the stylesheet used for the mathml spec has had some code
to do that (since before XSLt 1 was a REC:-) I should probably simplify
it these days using XSLT2 but it works well enough, lifting any block
level element, not just lists, out of a p.

> I'd have much preferred to provide for the literal inclusion of CSS from
> an additional file but haven't figured out how to do this simply
> [document(), no; unparsed-text(), no; xinclude, needs two passes ...].

why no for unparsed-text() ? The stylesheets work with just some minor
adjustments with XSLT 2 then unparsed-text ought to work well for
including css files as literal text. The MathML3 drafts are all produced
using xslt2 (saxon 8) using the xmlspec derived styleshseets at
Math/Group/Math/Group/spec/style/html/
       

> - make editors notes behave differently
something we find useful sometimes is that all (open) editors notes are
collected on the front page together with links back to the note and
also into the W3C Wiki (which means wiki pages for discusisng any issue
get created on demand by following the links)
see
http://www.w3.org/Math/Group/draft-spec/#openissues


David



________________________________________________________________________
The Numerical Algorithms Group Ltd is a company registered in England
and Wales with company number 1249803. The registered office is:
Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.

This e-mail has been scanned for all viruses by Star. The service is
powered by MessageLabs.
________________________________________________________________________