Re: Proposed changes to address issue-dbooth-3 (ambiguity)

David,


    If you wish for the WG to seriously consider your change, we need a
finite list of all changes that need to be made to the spec, including
non-normative text. If you can provide such a list for the WG and editor
in particular, it will help consideration of your change. However, at
this point in W3C Process we cannot afford to make commitments to
"open-ended" changes to the spec.

    Also, we cannot of course add in a mention of a potential note
unless the text of the Note is actually written.

    I would suggest doing these before suggesting any other changes, as
suggesting too many changes in an "open-ended" manner makes it
impossible for the WG to consider them. As you know due to your
experience in these matters, it is far better to have one solid
proposal, with test-cases and a list of textual changes, than many.

          thank


Booth, David (HP Software - Boston) wrote:
>> From: Jeremy Carroll [mailto:jjc@hpl.hp.com] 
>>
>> Booth, David (HP Software - Boston) wrote:
>>     
>>> Yes, and as I pointed out, that document was designed with 
>>> GRDDL in mind
>>> and *chose* to put a GRDDL transformation inside a default 
>>> attribute. [ . . . ]
>>>       
>> No it didn't.
>>
>> As is not uncommon practice, it put the namespace in a 
>> default attibute.
>>     
>
> Okay, I should have been more precise: it put a namespace that
> *indicated* a GRDDL transformation inside a default attribute.
>
>   
>> It also put the grddl namespace in a default attribute, in order to 
>> permit the document author to specify a further transform. 
>> Seems like a 
>> very plausible migration from a DTD based XML usage, to a 
>> GRDDL aware usage:
>> - keep using a DTD
>> - modify the DTD to allow document specific GRDDL transform
>> - add a namespace transform
>>
>> The example is not intended to be a baroque example to artificially 
>> construct a hole, but a useful simplification of likely 
>> real-world usage.
>>     
>
> This example illustrates variability both in the "transformation
> determination" step and the "transformation application" step.  The
> variability in the "transformation determination" step would be the same
> whether or not the proposed change is made, and the variability in the
> "transformation application" step could be controlled if the propoosed
> change were made.  
>
> So in this sense this example is also a good illustration of the fact
> that the proposed change would be clearly inferior to a change that
> would also eliminate variability in the "transformation determination"
> step.  I'm working on an alternate proposal that would remove that
> variability also.
>
>
> 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.
>  
>
>
>   


-- 
		-harry

Harry Halpin,  University of Edinburgh 
http://www.ibiblio.org/hhalpin 6B522426

Received on Tuesday, 19 June 2007 19:07:29 UTC