[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
Re: [xml-dev] XML aggregation question?
- From: "Andrew S. Townley" <ast@xxxxxxxxxxxx>
- To: "Henry S. Thompson" <ht@xxxxxxxxxxxx>
- Date: Mon, 28 Aug 2006 12:33:01 +0100
On Mon, 2006-08-28 at 12:18, Henry S. Thompson wrote:
> Well, for the phase you're in, and even the next phase, I'd encourage
> you to look at an all-XML no-DB solution. The kind of architecture
> I've used for e.g. an admissions management application (1000
> applications, 1.5K doc per applicant) works with a master document
> like this:
>
> <decisions xmlns:xi="http://www.w3.org/2001/XInclude">
> <decision>
> <xi:include href="a34034.xml"/> <!-- an <applicant> element -->
> <rank>32</rank>
> <outcome>Accept</outcome>
> </decision>
> <decision>
> <xi:include href="a34182.xml"/> <!-- an <applicant> element -->
> <rank>50</rank>
> <outcome>Pend</outcome>
> </decision>
> . . .
> </decisions>
>
> Convert this for your purposes into
> <statuses>
> <status value="xxx">
> <xi:include href="w34034.xml"/> <!-- a <widget> element -->
> </status>
> . . .
>
> Plus pipelines [1] which e.g. run XInclude followed by XSLT to extract
> appropriate views.
Hmm.... very interesting. It also solves one of my other issues which
was that potentially I needed to annotate or augment the small instances
with more information and/or embed them as a complex element into a
larger document (I realize this is essentially what you are talking
about in your 1997 paper).
> Obviously way too schematic, but gives you the idea, I hope.
Yep.
> Or you may want to have two layers of virtual documents, with one file
> per status, and
>
> ( echo "<statuses>" ; cat currentStatus/*.xml ; echo "</statuses>" ) | \
> [XIncl and XSLT pipeline]
Possibly, but possibly not. I'm still working out the
presentation/visualization that makes the most sense. But, in this
case, your virtual documents are essentially the cached "indexes" over
the data which need to be recreated every time the data changes. The
more indexes/views, the more overhead to keep them in sync: DB or no
DB.
>
> [1] http://www.markup.co.uk/
> [available for design consultancy contract :-]
I'll keep that in mind :)
Thanks for that,
ast
--
Andrew S. Townley <ast@atownley.org>
http://atownley.org
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]