Why is it that you feel the need to specify the XPaths ... is <require_db>
so very flexible that the database schema can be found elsewhere other than
where it already exists? Same for <ref_database> ... isn't that kind of
information only found where you can expect it to be found?
I appreciate the reply! I think what I'm after is confirmation that my
model isn't crazy, or that there is not some other more obvious way to
handle this problem of modeling N dependencies.
The answer to your question is no, I don't think it the database schema
will be found elsewhere, so I do believe I can map the essentials into
an XML element and embed the rest of the lookup information into XSLT
templates.
One worry I have is that, since I'm not yet comfortable thinking in XSLT's
terms I'm fear that I won't be able to model a feature that depends on
the notion of looping through elements. Basically I worry that I'll
end up reimplementing (badly) what XSL notation already provides.
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.
For example, let's say there is a feature "dblookup" which is written
in random language and it needs to read a flat-text configuration file:
$ cat /usr/local/etc/dblookup.conf
databases=(
"barrons_content", "oracle2.wsj.com:1234",
"barrons_subscribers", "oracle1.wsj.com:1234",
"wsj_content", "oracle2.wsj.com:1234",
"wsj_subscribers", "oracle1.wsj.com:1234"
)
One way to model this would be from the context of the site:
<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"/>
</list>
</config>
</feature>
</site>
That'd be simple to process via XSLT. 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.
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):
<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? -->
</list>
</config>
</feature>
<site name="intranet_wsj">
<use_feature name="dblookup">
<use_database dbserver="oracle1" dbname="barrons_content"/>
<use_database dbserver="oracle2" dbname="wsj_content"/>
<use_database dbserver="oracle1" dbname="barrons_subscribers"/>
<use_database dbserver="oracle1" dbname="wsj_subscribers"/>
</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"/>
</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. :(
Jim Robinson
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
James A. Robinson
jim(_dot_)robinson(_at_)stanford(_dot_)edu
Stanford University HighWire Press http://highwire.stanford.edu/
650-723-7294 (W) 650-725-9335 (F)
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list