Subject: Re: [xsl] modeling relationships for efficent XSL processing From: "James A. Robinson" <jimr@xxxxxxxxxxxxxxxxxxxxx> Date: Thu, 26 Feb 2004 11:33:12 -0800 |
> 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.robinson@xxxxxxxxxxxx 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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] modeling relationships fo, G. Ken Holman | Thread | Re: [xsl] modeling relationships fo, G. Ken Holman |
RE: [xsl] A strange problem..., Andreas L. Delmelle | Date | RE: [xsl] CSS within XSL, Josh Canfield |
Month |