Re: Conformance Labels

After reading this last two e-mails, maybe we should stop thinking in
terms of "conformance labels" because conformity does require the state
of the Web to be in a certain state (i.e. the URI of the transformation
to return an understood transform) so that we can guarantee whether or
not a GRDDL implementation working over a given document is
"conformant", but more of a "standard vocabulary" we can use both
internally and externally for talking about the various components of a
GRDDL transformation process that can help with clarity and education. I
think these "conformance labels" and "standard vocabulary" are actually
different things. For example, a "standard vocabulary" could be used to
describe a GRDDL system where the URI of the transform is broken (say
returns a 404), by saying the "The GRRDL document cannot be transformed
because...blah blah.."

I'm not sure if our vocabulary has been internally consistent or
consistent in our docs. I suspect individual people might be and so the
GRDDL spec might be, but I have run into weird neologisms like
"GRDDL'ble" and "the GRDDL", so we should at least get straight if GRDDL
is a noun, a verb, or an adjective :)





Dan Connolly wrote:
>>
>> I think the dereference terminology covers the criteria regarding the 
>> state of the web.
>>     
>
> Well, yes, it's clear now. You're really proposing to define
> conformance of GRDDL documents in such a way that a document
> can be conforming one day and not conforming the next, with no
> changes to the document itself.
>
> That's pretty much the opposite of what I think is helpful in
> a conformance label. I much prefer no conformance label.
>
>
>   
>>> I can imagine them, but I don't want to encourage them by giving
>>> conformance labels to them.
>>>       
>> Fair enough.  How about:
>>
>> A GRDDL Processor is a software agent which supports all of the possible 
>> mechanisms that a GRDDL Document can use to register transformations that 
>> preserve it's meaning. <insert appropriate description of supported transformation languages. XSLT, etc..>.
>> <insert appropriate language about local policy and how they can effect 
>> the GRDDL processor's determination of which transformation algorithms to 
>> apply?>
>>     
>
> I can imagine replacements for those <insert>s that I might
> find acceptable, but it doesn't look easy to find them.
> I think it's more trouble than it's worth.
>
>   


-- 
		-harry

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

Received on Tuesday, 5 September 2006 21:18:24 UTC