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.
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format