[
Lists Home |
Date Index |
Thread Index
]
Title: RE: [xml-dev] An Architecture for Limericks (was Limericks, Stupidity, and Reality)
Actually, extra processing to test rhyming, syllabification and so forth are redundant because limericks are not actually required to rhyme, and even the short and long apply a constraint that is not required by the genre. An example I remember from a book of limericks I had as a child:
There once was a man from Japan,
Who wrote rhyme that just wouldn't scan,
When they said, "But the thing
"Doesn't go with a swing",
He replied "Yes, I know, but I always like to try to get as many words into the last line as I possibly can."
There was one in there that didn't rhyme also, but I can't remeber it off the top o my head, and it shouldn't be too hard to make one up.
John
_________________________________________________________
John Anderson
CTO Barbadosoft
The XML Management Company
+31 (0)20 750 7582 / +31 (0)6 65 347 448 / www.barbadosoft.com
- putting the "X" in "XML" -
-----Original Message-----
From: Jonathan Robie [mailto:jonathan.robie@softwareag.com]
Sent: 12 January 2002 21:27
To: Mike Champion; xml-dev@lists.xml.org
Subject: [xml-dev] An Architecture for Limericks (was Limericks,
Stupidity, and Reality)
Computer scientists don't write limericks without designing a general
architecture for limericks.
Suppose I wanted to write the limerick constraint testing system that Mike
wants. I would probably want to separate concerns among several different
modules, and I would like to make it easy to look at the results of each
step. I think that I am unlikely to persuade my limerick authors to write
their limericks in finely grained markup, so I suspect they will give me
texts like this:
There was a young lady named Bright
Whose speed was much faster than light.
She set out one day,
in a relative way,
And returned on the previous night.
With a Perl script, it is fairly easy to mark up the lines of this poem,
and I would like to do this before running my syllabification, because it
is quite likely that the syllabification engine will lose my whitespace,
which is important for identifying the lines. If I already know this is a
limerick, I could choose to divide this up into long and short lines from
the beginning:
<limerick>
<long>There was a young lady named Bright</long>
<long>Whose speed was much faster than light.</long>
<short>She set out one day,/short>
<short>in a relative way,</short>
<long>And returned on the previous night.</long>
</limerick>
For testing the rhyme scheme, further markup is probably not helpful. Also,
I am probably not going to keep any markup I use for testing whether a line
scans, so I will use a schema adjunct to declare the constraints on this
poem. I use standard poetry terms for the metrical feet - here is a table
of the terms, compared with their representation in Cowan Normal Form (CWF):
iamb da-DUM
anapest da-da-DUM
tertius paeon da-da-DUM-da
Here is a Schema Adjunct that declares the constraints on a limerick:
<schema-adjunct targetNamespace="http://www.example.com/limerick"
xmlns="http://www.schema-adjuncts.org/namespaces/2001/07/saf">
<global>
<rhymes>
<line select="limerick/long[1]" />
<line select="limerick/long[2]" />
<line select="limerick/long[3]" />
</rhymes>
<rhymes>
<line select="limerick/short[1]" />
<line select="limerick/short[2]" />
</rhymes>
</global>
<element context="short">
<scans>
<sequence>
<choice>
<iamb /> <!-- da dum -->
<anapest /> <!-- da da dum -->
</choice>
<choice>
<iamb />
<anapest />
</choice>
</sequence>
</scans>
</element>
<element context="long">
<scans>
<sequence>
<choice>
<iamb />
<anapest />
</choice>
<choice>
<iamb />
<anapest />
</choice>
<choice>
<iamb />
<anapest />
<tertius.paeon /> <!-- da da dum da -->
</choice>
</sequence>
</scans>
</element>
</schema-adjunct>
So far, I have written no code, so I have no software that will tell me
whether a line scans or whether a set of lines rhyme. However, I do have a
way of declaring the structure of a poem in a Schema Adjunct, and I can use
it to describe the structure of other kinds of poems as well. The specific
algorithms for testing these constraints is up to the implementations, but
I have also modularized the implementation.
I have also made the implementation easier to test - I can write test
suites that take sets of words that are presumed to rhyme or not to rhyme,
and see whether my system handles them correctly. I can do the same for
scansion.
Now suppose that more than one rhyming engine exists, and more than one
scansion engine exists. Do these engines agree? If not, how do they
disagree? Are there bugs in one or both of the engines, or are their
answers both reasonable? If the answers to these questions are important to
me, a concrete representation of the output of the engines may be very
helpful. Without it, I would have to compare the source code of the
systems, or try to create exhaustive sets of tests that would give me
indications of how they work.
For instance, suppose I ask the software to test whether the following scans:
<long>There was a young lady named Bright</long>
If it says that it does not, I may not be sure whether there is a bug in my
software or an error in the line of the limerick. If there is a bug in my
software, I may not know if the bug is in the syllabification per se, in
the stress assigned to syllables, or in the comparison of the
syllabification and stress to that required of a long line in a limerick.
For testing purposes, output like the following can be very helpful indeed:
<long>
<da>There</da>
<dum>was</dum>
<da>a</da>
<da>young</da>
<dum>la</dum>
<da>dy</da>
<da>named</da>
<dum>Bright</dum>
</long>
Not only is this useful for testing, it is also useful for defining
interfaces. For instance, I might well have a system that takes the above
representation and compares it to the declared scansion for the long line
of a limerick, as given in the above schema adjunct. This would be very
simple to write.
In general, when designing complex systems, I think it is very helpful to
think in terms of declarative, testable architectures.
Jonathan
-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of OASIS <http://www.oasis-open.org>
The list archives are at http://lists.xml.org/archives/xml-dev/
To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl>
The information transmitted by this e-mail message is intended solely for the use of the person to whom or entity to which it is addressed. The message may contain information that is privileged and confidential. Disclosure, dissemination, distribution, review, retransmission to, other use of or taking any action in reliance upon this information by anyone other than the intended recipient is prohibited. If you are not the intended recipient, please do not disseminate, distribute or copy this communication, by e-mail or otherwise. Instead, please notify us immediately by return e-mail (including the original message with your reply) and then delete and discard all copies of the message.
Although we have taken precautions to minimize the risk of transmitting viruses we nevertheless advise you to carry out your own virus checks on any attachment to this message. We accept no liability for any loss or damage caused by viruses.
| 