- From: Chimezie Ogbuji <ogbujic@bio.ri.ccf.org>
- Date: Tue, 17 Oct 2006 14:46:36 -0400 (EDT)
- To: GRDDL Working Group <public-grddl-wg@w3.org>
On Tue, 17 Oct 2006, Murray Maloney wrote: > As a matter of opinion, I think that it would be distracting to include a > discussion of why we didn't follow an alternate design route. The spec > should expose those design routes we have chosen. Otherwise the spec > will be filled with a lot of verbiage that it doesn't need. On the contrary, I don't think there is a more appropriate place to spell out this distinction than in the specification. GRDDL suggests an alternative route that is more robust for sure, but the GRDDL mechanism only accounts for *one* particular goal in transforming content. XSLT can be used (in very similar fashion) to generate other artifacts (from the same source document) for very different ends and I think you do more harm than good in not spelling out this distinction *especially* when you consider how ubiquitous support for xml processing PIs is within browsers. What I'm suggesting isn't so much a justification of not using PIs but rather being clear about how the GRDDL mechanisms relates to similar transformation mechanisms to give an appropriate context for (web client) implementors who will undoubtably have to reconcile this distinction. > If you suggesting that we add PIs as an additional mechanism for either > identifying the GRDDL namespace or for identifying GRDDL links, > then I think you face an uphill battle against the Web Architecture. I'm not suggesting accomodating PIs within GRDDL, but giving the appropriate context for implementors who have will have to contend with the various, automated ways XML content will be processed within their architecture - PI's being the most prominent example. Chimezie Ogbuji Lead Systems Analyst Thoracic and Cardiovascular Surgery Cleveland Clinic Foundation 9500 Euclid Avenue/ W26 Cleveland, Ohio 44195 Office: (216)444-8593 ogbujic@ccf.org
Received on Tuesday, 17 October 2006 18:46:57 UTC