Re: Creating additional depth from flat structure using XSLT

[Wendell Piez <wapiez at mulberrytech dot com>]

Ed,

This is getting fun.

I'd start by elevating the value of that stylename attribute to a real
element type name, to get access to this information more easily (since
it's crucial.) So instead of

><p stylename="heading1" >
>  <string>More Money for All Amendment
>  </string>
></p>
><p stylename="section">
>  <string>1.(1)Clause 8 (1) (a) of the</string>
>  <string italic="on">More Money for All Amendment</string>
>  <string> is deleted and the following substituted:</string>
></p>

You have

><heading1>
>  <string>More Money for All Amendment
>  </string>
></heading1>
><section>
>  <string>1.(1)Clause 8 (1) (a) of the</string>
>  <string italic="on">More Money for All Amendment</string>
>  <string> is deleted and the following substituted:</string>
></section>

You can do this with <xsl:element name="@stylename">...</xsl:element>
elements. In general, I think you'll gain quite a bit from pre-processing
your RTF-XML into something cleaner and more legible.

As for reintroducing your hierarchy... this will be a pretty trick. The
problem is in those permissive content models

<!ELEMENT section  (clause* | subsection*)* >
(which might as well be <!ELEMENT section  (clause | subsection)* > )

and
<!ELEMENT amendment  (heading1,(section | clause*)*)* >

which means that a clause appearing after an amendment (or section) in the
current flat form could be either within a section (or subsection), or not.
That's a problem. If you could be sure they were really

<!ELEMENT section  (clause*, subsection*) >
<!ELEMENT amendment  (heading1, clause*, section* >

That'd be a little better. Inside the amendment or section you could
process all its following-sibling clauses that had no previous-sibling
sections or subsections.

Then your problem resolves to each time you generate an amendment or
section, you need to take any clauses directly following it to appear
inside it -- and then skip them when they are hit on their own account.
That is, your clause template must check to see whether it has any
subsection siblings.

Operations like
  <xsl:apply-templates
select="following-sibling::clause[not(preceding-sibling::subsection)]"/>

inside the section template

and
<xsl:template match="clause">
  <xsl:if test="not(following-sibling::(section) and
not(following-sibling::subsection)">...</xsl:if>
</xsl:template>

might do the trick.

Please note I'm just "thinking aloud," and haven't tested anything. And
you're right, people get paid real money for this stuff. :-)

Good luck,
Wendell Piez

At 01:52 PM 4/5/00 -0400, you wrote:
>The task here is to create enclosing levels around a series of more-or-less
>sibling elements....
 Here is a snippet (long),again from Rick Geimer's RTF2XML:
>
><p stylename="heading1" >
>  <string>More Money for All Amendment
>  </string>
></p>
><p stylename="section">
>  <string>1.(1)Clause 8 (1) (a) of the</string>
>  <string italic="on">More Money for All Amendment</string>
>  <string> is deleted and the following substituted:</string>
></p>
><p stylename="clause">
>  <string>(a)the entrepreneur or, if there is more than one entrepreneur,
>one or more of the entrepreneurs.
>  </string>
></p>
><p stylename="subsection">
>  <string>(2)Subsection 8(1) of the Amendment is amended by striking out
>'or' at the end of clause (e), by adding 'or' at the end of clause (f) and
>by adding the following clause:
>  </string>
></p>
><p stylename="clause">
>  <string>(g)a person appointed as administrator by the Boss under section
>71.
>  </string>
></p>
...
>The idea is to try to wrap the 'p' elements into a hierarchy based on the
>value of the 'stylename' attribute. The output *might* have the following
>structure:
>
><?xml version="1.0" encoding="ISO-8859-1"?>
><!DOCTYPE amendment [
><!ELEMENT amendment  (heading1,(section | clause*)*)* >
><!ELEMENT heading1  (#PCDATA) >
><!ELEMENT section  (clause* | subsection*)* >
><!ELEMENT clause  (para+) >
><!ELEMENT subsection  (clause*) >
><!ELEMENT para  (#PCDATA) >
>]>
>
>I suspect most of you get paid real money for information about this kind of
>thing....

======================================================================
Wendell Piez                            mailto:wapiez@mulberrytech.com
Mulberry Technologies, Inc.                http://www.mulberrytech.com
17 West Jefferson Street                    Direct Phone: 301/315-9635
Suite 207                                          Phone: 301/315-9631
Rockville, MD  20850                                 Fax: 301/315-8285
----------------------------------------------------------------------
  Mulberry Technologies: A Consultancy Specializing in SGML and XML
======================================================================


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list