Lists Home |
Date Index |
> That's precisely what I'm disagreeing with... I'm becoming
> more & more convinced that inclusion and aggregation have so
> much application-specific hair, and the cost of trying to
> model them generally is so high, that we should just kick
> them out of the syntax and at the level of *interoperability*,
> we should talk in terms of whole fully composed XML documents.
I agree with you Tim, the more I think about aggregation the more I find
that to include all aggregation rules in a single spec would lead to a book
bigger than "war and Peace" from Tolstoy :-).
For instance, we have aggregation rules based on template matching: XSLT
aggregation rules based on device/context profile: esi (ref:
aggregation/synchronization rules based on priority and content (ref:
and many more aggregation mechanisms invented by members of this list...
So, yes I agree with you, aggregation has too many heads to be confined in a
single hat. However I should say that XSLT taken as an intepreter could be
used to implement several aggregation rule mechanisms.
Didier PH Martin.