RE: An alternative usecase to consider for the ambiguity proposals

It's bizarre how long it took for this email to arrive.  The mail
servers must have started to treat email on the ambiguity issue as
PRIORITY=SPAM.   :)


David Booth, Ph.D.
HP Software
+1 617 629 8881 office  |  dbooth@hp.com
http://www.hp.com/go/software

Opinions expressed herein are those of the author and do not represent
the official views of HP unless explicitly stated otherwise.
 

> -----Original Message-----
> From: public-grddl-wg-request@w3.org 
> [mailto:public-grddl-wg-request@w3.org] On Behalf Of Chimezie Ogbuji
> Sent: Wednesday, June 27, 2007 9:23 AM
> To: GRDDL Working Group
> Subject: An alternative usecase to consider for the ambiguity 
> proposals
> 
> 
> Just a point of illumination meant to contribute to an "informed"
> conversation and decision about the ambiguity issue.  This came up
> during dialog with David and John but was not re-iterated in 
> the mailing
> list at any point, so I'll repeat it here for the benefit of 
> the Working
> Group members.  The suggested corrections to address ambiguity are
> motivated by David's usecase in which pre-emptive XInclude elaboration
> (automatic expansion of XInclude) is *not* what the author 
> has in mind:
> the quoting XInclude scenario.  Consider an alternative usecase where
> pre-emptive XInclude elaboration is *exactly* what the author had in
> mind for a 'Faithful Rendition'.  Lets say the GRDDL source document
> was:
> 
> <?xml version='1.0'?> 
> <html xmlns="http://www.w3.org/1999/xhtml"
>       xmlns:xi="http://www.w3.org/2001/XInclude"
>       xmlns:grddl='http://www.w3.org/2003/g/data-view#'">
>   <head profile="http://www.w3.org/2003/g/data-view">
>     <xi:include href="otherTransform.xml"/>
>     <title>..</title>
>   </head>
>   <body>..</body>
> </html>
> 
> And otherTransform.xml was:
> 
> <?xml version='1.0'?> 
> <link 
>   xmlns="http://www.w3.org/1999/xhtml" 
>   rel="transformation" 
>   href="someOtherTransform.xsl"/>
> 
> Notice, if the second document is included (which is the 
> author's intent
> here), before the original source is 'searched' for 
> transforms, then the
> additional transform is picked up (and applied).  However, if 
> the second
> document is *not* included, the additional transform is *not* picked
> up. 
> 
> My (mostly rhetorical) question is which of the GRDDL specifications
> (including the current editor's draft and the various proposals)?:
> 
> 1. Can support both usecases
> 2. Will be in compliance with the xmlFunctions-34 resolution
> 3. Can be subject to the eventual XML Processing Model 
> specification as
> a way (independent of GRDDL) for "an author, consumer, or 
> application to
> guide this process" [1]
> 
> By 'this process' the XML Processing Model WG Charter is 
> speaking of the
> process of determining "Which if any of the transformations 
> signalled by
> aspects of an XML document should be performed, and in what order"
> 
> [1]http://www.w3.org/2005/10/xml-processing-model-wg-charter.h
> tml#xml-scope
> 
> -- 
> 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
> 
> 
> ===================================
> 
> 
> 
> 
> Cleveland Clinic is ranked one of the top 3 hospitals in
> America by U.S.News & World Report. Visit us online at
> http://www.clevelandclinic.org for a complete listing of
> our services, staff and locations.
> 
> 
> Confidentiality Note:  This message is intended for use
> only by the individual or entity to which it is addressed
> and may contain information that is privileged,
> confidential, and exempt from disclosure under applicable
> law.  If the reader of this message is not the intended
> recipient or the employee or agent responsible for
> delivering the message to the intended recipient, you are
> hereby notified that any dissemination, distribution or
> copying of this communication is strictly prohibited.  If
> you have received this communication in error,  please
> contact the sender immediately and destroy the material in
> its entirety, whether electronic or hard copy.  Thank you.
> 
> 
> 
> 
>

Received on Wednesday, 27 June 2007 18:00:22 UTC