Re: [xsl] modeling relationships for efficent XSL processing

Subject: Re: [xsl] modeling relationships for efficent XSL processing
From: "G. Ken Holman" <gkholman@xxxxxxxxxxxxxxxxxxxx>
Date: Thu, 26 Feb 2004 20:58:18 -0500
At 2004-02-26 11:33 -0800, James A. Robinson wrote:
Basically my task is this: somehow organize all information about a
set of databases, features, and sites and be able to dynamically generate
configuration files for a number of configurations, and for a number of
output formats.

Sounds like a job for ID/IDREFS.


But I don't want to keep repeating
the same information in the XML file.  I keep going back to the idea of
trying to "normalize" the XML so that one doesn't have to keep repeating
information.

Identify each of the normalized components using an ID-typed attribute, and point to them with IDREF or IDREFS attributes.


The example above requires not only that the person writing the <site>
node know which databases a feature uses, it requires embedding the
actual model of the feature and it's configuration file into the <site>
element itself. That seems bad to me.

I'd like to figure out a way to have the human deal with normalized data
and have the computer figure out how to expand everything into the final
format. So two node sets (and you can see by the comment in the first
I can't figure out how it'd be modeled):

If these two node sets are in one XML document, then you can use the XML mechanism for referencing: a unique ID-typed attribute to identify each thing being referenced, and pointing to one using an IDREF-typed attribute or pointing to many using an IDREFS-typed attribute.


<feature name="dblookup">
<!-- this feature requires 1 or more databases -->
<config name="/usr/local/etc/dblookup.conf">
<list name="databases">
<!-- somehow indicate a variable list of dbname_server_pair nodes? -->

Use idrefs="pair1 pair2 pair3 pair4" perhaps as in:


<list name="databases" nameservers="pair1 pair2 pair3 pair4"/>

                </list>
        </config>
</feature>

<site name="intranet_wsj">
        <use_feature name="dblookup">
                <use_database dbserver="oracle1" dbname="barrons_content"/>

id="pair1"


<use_database dbserver="oracle2" dbname="wsj_content"/>

id="pair2"


<use_database dbserver="oracle1" dbname="barrons_subscribers"/>

id="pair3"


<use_database dbserver="oracle1" dbname="wsj_subscribers"/>

id="pair4"


        </use_feature>
</site>

Get transformed into:

<site name="intranet_wsj">
<feature name="dblookup">
<config name="/usr/local/etc/dblookup.conf">
<list name="databases">
<dbname_sever_pair dbname="barrons_content" dbserver="oracle1"/>
<dbname_sever_pair dbname="wsj_content" dbserver="oracle2"/>
<dbname_sever_pair dbname="barrons_subscribers" dbserver="oracle1"/>
<dbname_sever_pair dbname="wsj_subscribers" dbserver="oracle2"/>

Provided your XML instance begins with:


<!ATTLIST use_database id ID #REQUIRED>

then your XSLT can use:

 <xsl:for-each select="id(@nameservers)">
   <dbname_server_pair dbname="{@dbname}" dbserver="{@dbserver}"/>
 </xsl:for-each>

                </list>
            </config>
        </feature>
    </site>

That lets the human deal with the bits of information important to them,
and require they have intimate knowledge of every feature's exact makeup.
Is this making any sense to people> I'm worried I'm muddling my goals. :(

Not at all ... your desire to "normalize" the XML is (or at least should be!) very natural and I do it all the time I can (I'm a big fan of ID/IDREF). There are 403 ID-typed attributes in my XML instance supporting my Secretariat's Report for the ISO committee for SGML: http://www.jtc1sc34.org/ has a ZIP file of the XML and associated RNC where the attribute types are declared and validated. Every document points to the author's information using IDREF. Same with every document pointing to its project, every author pointing to its national body .... all validated with ID/IDREF validation.


All of my links come out in the resulting HTML as hyperlinks, whereas you plan to replicate the data in the resulting transformation.

I hope this helps.

............................ Ken

--
US XSL training: Washington,DC March 15; San Francisco,CA March 22
World-wide on-site corporate, government & user group XML training
G. Ken Holman                 mailto:gkholman@xxxxxxxxxxxxxxxxxxxx
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/s/
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
Male Breast Cancer Awareness  http://www.CraneSoftwrights.com/s/bc


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



Current Thread