Michael Beddow | 1 Feb 2005 10:54

Re: Valid HTML Considered Harmful?

Among off-list responses to my posting re grouping via keys in this thread
was a note from Wendell suggesting the application of what, with
characteristic generosity, he described as a "tweaklet", but is in truth the
correction of a pretty major goof on my part. As tends to be the case with
such goofs at their very worst, the effect isn't visible on the sample
document, but it would have definitely unwanted consequences in a longer
one.

It concerns my (mis)use of the XSLT union operator "|". Ironically in my
production code (nothing to do with xhtml generation, but everything to do
with grouping) from which I adapted the example for posting, I had it right;
but somehow I persuaded myself while writing the posting that the original
formulation could be "abbreviated". Big mistake.

My error is at the point where I say

> So, leaving our predicate in place to filter the <p>s as
> before, we extend the XPath to select children of those filtered<p>s,
> whether they are text nodes or element children (along with any text
> descendants those children may have), giving:
> match = "p[q/ <at> rend='block']/text()|*"

The narrative part is correct, but the sample XPath doesn't do what I claim.
In XSLT, the operator "|" evaluates  the XPath expressions either side of it
and returns the union of the two resultant nodesets. What I wanted was the
union of all the immediate text children of <p>s with at least one q child
having  <at> rend='block' (which my expression left of the "|" indeed matches)
and the element children of <p>s matching the same filtering predicate. But
what I stupidly placed to the right of the union operator in my attempt at
terseness (!) was the bare expression "*", which of course selects all
(Continue reading)

Wendell Piez | 1 Feb 2005 17:58
Favicon

Re: Valid HTML Considered Harmful?

At 04:54 AM 2/1/2005, Michael wrote:
>  The later grouped <p>s would
>still then all emerge fine, but not before the faith of any reasonable
>person in my competence, or the usability of XSLT, or maybe both, had been
>badly shattered.

Maybe so, people's expectations of magic being what they are, but I say
"Feh". Bugs, and the need to fix them, are what software development is all
about.

I'd also be curious to know if Michael or anyone has worked out an XSLT 2.0
solution. The grouping constructs there should be a big help. I haven't,
yet -- no time to give (*sigh*).

The forward-stepping approach I mentioned earlier is also worth taking a
look at:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">

   <xsl:template match="p">
     <p>
       <xsl:apply-templates select="node()[1]" mode="tuck"/>
     </p>
     <xsl:apply-templates select="q[ <at> rend='blockquote'][1]"/>
   </xsl:template>

   <xsl:template match="q[ <at> rend='blockquote']" mode="tuck"/>

   <xsl:template match="node()" mode="tuck">
(Continue reading)

Francois Lachance | 3 Feb 2005 02:48
Picon
Picon

Re: TAN: Those damn emacs codes (was: Re: Editors and medium-tech

The chord question might be interestingly approached from the perspective
of the one-handed user.

Someone once wrote to me off list:

<quote>Oh, if we could remake the interface!  (I'd love to be able to
keyboard one-handedly, leaving the other to point.)</quote>

Don't some of us do that already? In a Windows environment I will set up
the mouse on the left hand side and navigate or invoke commands with a
combo of cursor movement, mouse clicks and keyboard short cuts.

For Emacs it sits on the right. It only becomes apparent now that the left
hand gets a fine workout in Unix interfaces. Could those chords have a
piano playing origin?

Peter wrote:

> In the Emacs configuration I'm developing, I am trying to eliminate
> chords (keystroke sequences) for most common editing tasks.  At the
> moment I have an "extreme" configuration that binds safe-buffer to
> Ctrl-s, which is "save file" in many (most?) applications, and I also
> have a different, less extreme configuration that binds it to F1,
> leaving Ctrl-s free for its default meaning of isearch-forward.
>

--
Francois Lachance, Scholar-at-large
http://www.chass.utoronto.ca/~lachance/jardin

(Continue reading)

Francois Lachance | 3 Feb 2005 03:15
Picon
Picon

Re: Editors and medium-tech people

Triple slash Peter signed the following:

> [Incidentally, in the earlier stages of my research I dissected the
> interfaces of some 20 XML editors, and found that almost every one of
> them provided the identical set of about 50 markup-based operations.
> Perhaps unsurprising, given that these operations can be deduced to
> be required in order to enable or ease the editing of markup to
> conformance with SGML/XML, but instructive that "all XML editors have
> the same set of markup-editing features" no matter what the marketing
> or proselytisation blurb says. Among the very few missing features
> was the oddity that Emacs/psgml/xxml has a "split element" command
> but no "join-element-to-preceding-of-the-same-type" command.]

With Lisp and XSLT, can a macro be built that picks up the current
location of the cursor, pass that somehow to an XSLT transform and outputs
the result to overwrite the buffer? This opens to a larger question of
navigating a document instance via XPATH expressions. Depending on the
complexity of the markup, it might sometimes be nice to issue the command
Go to the last descendant of the nth sibling...

--
Francois Lachance, Scholar-at-large
http://www.chass.utoronto.ca/~lachance/jardin

2005 Year of Comparative Connections. DIA: Comparative connections? LOGZ:
Connection, first. Comparison, next. DIA: Check. Comparable ways of
connecting. LOGZ: Selection outcomes, first. Comparative Connections,
next.

(Continue reading)

David Sewell | 3 Feb 2005 21:32
Favicon

XSLT stylesheet for verifying TEI table integrity

Re: Daniel's call for thoughts about an XSLT fragment wiki:

> xslt fragments on the other hand seem a slightly different type of
> thing, and one that might work well in a wiki environment: people
> contribute them gladly to lists, and several--the Muench method, the
> "Wendell wandle" (or was it Piez process) have even picked up names. A
> Wiki might be an attractive in-between-step between posting to a list
> and submitting to a refereed journal.
>
> Opinions?

It's a good idea. My only question would be whether the postings can be
versioned so as to show development, and possibly revert to previous
versions if necessary.

Meanwhile, I have written a special-purpose XSLT script that people are
invited to test and hammer on. It is designed to check the structural
integrity of TEI-encoded tables. It tests tables that have these
characteristics:

   * a <table> has a set number of columns that is identical for each row
   * the target number of columns is declared in a table/ <at> cols attribute
   * cells may span rows and columns; they must have  <at> cols and/or  <at> rows
     attribute values if they do so

The script simply goes through each row of a table and check to see
that the number of actual + virtual cells equals the number of
columns declared in table/ <at> cols. This would be simple if it weren't for
the fact that some "virtual cells" actually begin in preceding rows, via
row-spanning with the  <at> rows attribute on a cell.
(Continue reading)

Sebastian Rahtz | 4 Feb 2005 01:01
Picon
Picon

Re: XSLT stylesheet for verifying TEI table integrity

David Sewell wrote:

>It's a good idea. My only question would be whether the postings can be
>versioned so as to show development, and possibly revert to previous
>versions if necessary.
>
>
yes, good Wikis do work like that

>It tests tables that have these
>characteristics:
>
>   * a <table> has a set number of columns that is identical for each row
>   * the target number of columns is declared in a table/ <at> cols attribute
>
>
if you have already tested the first, the second is surely redundant?

--
Sebastian Rahtz
Information Manager, Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

OSS Watch: JISC Open Source Advisory Service
http://www.oss-watch.ac.uk

Daniel O'Donnell | 3 Feb 2005 22:50
Picon

Re: XSLT stylesheet for verifying TEI table integrity

The Wiki we have does versioning (It's the wikipedia's software,
actually). We get link-spammed every so often right now (I'm looking
into whether I can require you to sign up before editing something), and
I then need to be able to role things back. It also has an RSS server
announcing major edits and new items.

Do I take this as a vote? With Conal that's two. Probably enough to get
going.
-dan

Sebastian Rahtz wrote:
> David Sewell wrote:
>
>
>>It's a good idea. My only question would be whether the postings can be
>>versioned so as to show development, and possibly revert to previous
>>versions if necessary.
>>
>>
>
> yes, good Wikis do work like that
>
>
>>It tests tables that have these
>>characteristics:
>>
>>  * a <table> has a set number of columns that is identical for each row
>>  * the target number of columns is declared in a table/ <at> cols attribute
>>
>>
(Continue reading)

Sebastian Rahtz | 3 Feb 2005 23:02
Picon
Picon

Re: XSLT stylesheet for verifying TEI table integrity

Daniel O'Donnell wrote:

>The Wiki we have does versioning (It's the wikipedia's software,
>actually). We get link-spammed every so often right now (I'm looking
>into whether I can require you to sign up before editing something), and
>I then need to be able to role things back. It also has an RSS server
>announcing major edits and new items.
>
>Do I take this as a vote?
>

There is a plan for the TEI web site to have a wiki
server as well. Can you hang on for a week or two to
see if that comes off?

--
Sebastian Rahtz
Information Manager, Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

OSS Watch: JISC Open Source Advisory Service
http://www.oss-watch.ac.uk

David Sewell | 3 Feb 2005 23:09
Favicon

Re: XSLT stylesheet for verifying TEI table integrity

On Fri, 4 Feb 2005, Sebastian Rahtz wrote:

> > It tests tables that have these
> > characteristics:
> >
> >   * a <table> has a set number of columns that is identical for each row
> >   * the target number of columns is declared in a table/ <at> cols attribute
> >
> if you have already tested the first, the second is surely redundant?

Rephrase the above to "It tests tables that are *supposed to* have
these characteristics".

Point being that the following is a perfectly valid TEI table:

         <table cols="3" rows="1">
            <row><cell>one</cell><cell>two</cell><cell>three</cell></row>
            <row><cell>one</cell></row>
         </table>

even though its actual form does not fit its description. So the
stylesheet simply enforces the description by reporting discrepancies.

David

--
David Sewell, Editorial and Technical Manager
Electronic Imprint, The University of Virginia Press
PO Box 400318, Charlottesville, VA 22904-4318 USA
Courier: 310 Old Ivy Way, Suite 302, Charlottesville VA 22903
(Continue reading)

Conal Tuohy | 3 Feb 2005 23:48
Picon
Picon
Favicon

Re: Valid HTML Considered Harmful?

> -----Original Message-----
> From: Conal Tuohy

> I wrote a stylesheet for this same purpose - what I called
> "partitioning" - to flatten the structure of nested TEI

I have posted this stylesheet at the following location:
http://www.nzetc.org/downloads/make-partitions.xsl

It's a bit of a dog, but fairly easy to use:

e.g. to move <hr> elements out from inside <p> elements up to the same level:

     <xsl:template match="p">
       <xsl:call-template name="make-partitions">
         <xsl:with-param name="delimiters" select=".//hr"/>
       </xsl:call-template>
     </xsl:template>

example input:

     <p>
       Blah blah blah
       <hr/>
       blah blah
       <i>
         blah blah
         <hr/>
         blah blah
       </i>
(Continue reading)