Cart
[Home] [By Thread] [By Date] [Recent Entries]
Hi Tim, Tim said: > 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. Didier replies: 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: http://www.esi.org) aggregation/synchronization rules based on priority and content (ref: http://www.syncml.org) 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. Cheers Didier PH Martin.
|
