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 12:03:18 -0500
Sorry, James, I didn't look closely enough at your original instance to see that my distillation of your XPaths matched your original proposal ... so I guess I miss the nature of your requirement for flexibility.

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?

Sorry for the wasted bandwidth in the earlier message.

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

At 2004-02-26 11:21 -0500, I wrote:
At 2004-02-26 07:13 -0800, James A. Robinson wrote:
So I've got databases which don't depend on anything, features which
depend on a database type, and sites which depend on features and the
specific database of the type required by the each feature. I find myself
wanting to model things using XPATH notation:

But just how flexible do you need these XPath addresses to be?

<require_db xpath="/dbservers/dbserver/dbname/schema[@name='subscriber_db']"

Could you say:

<require_db schema="subscriber_db"/>

and then within the handling of require_db hardwire the rest of the XPath:


<ref_database xpath="/dbservers/dbserver[@name='oracle1']/dbname[@name='wsj_subscribers']"/>

Could you say:

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

and then within the handling of ref_database hardwire the rest of the XPath:

  <xsl:value-of select="/dbservers/dbserver[@name=current()/@dbserver]/

That way you would have an element type for each of your (I suspect limited set of) possible XPath hardwired addresses where the soft components needed for lookup are supplied as attributes of the element.

But it would only work if you did, indeed, have a limited set of possible XPaths and it was not totally generalizable.

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.
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
Male Breast Cancer Awareness

XSL-List info and archive:

Current Thread