RE: [July F2F]] Proposed wording on Conformance and Conformance Claims

Hi Jason

The answers to your questions are (to the best of my knowledge)

GV1 - all of the material from that URI would be in the authored unit
 
GV2 - all of the authored units that are within the authored unit at that
URI would be included. 

GV3 - we were not allowing one to scope out authored units within an
authored unit.  If they don't have an access claim then you can't make an
access claim on the parent.  (at least that is what we were proposing for
discussion.  Everything else looked invalid to us)

I also pasted these comments in context below.

Gregg



> 
 > 
 > Regarding the first comment -- 
 > Thanks for the definition of authored unit.     I'm not sure of your
 > ambiguity.   If it has a URI then it is what is at that URI.  
 > 
 > See also the other definition which says that a claim for any authored
unit
 > covers any other authored units within it.  That handles the concern.
Yes?
 > No? 

No, not really. The question is this: what is the scope of the
resource to which the URI refers? For the sake of simplicity let's
suppose the HTTP protocol. What gets returned in response to an HTTP
request can depend very much on the delivery context, e.g., the
specified language or character set, the type of user agent, etc. So
do we interpret the authored unit as including every possible content
that can be returned in response to an HTTP request for that URI?

GV1 - all of the material from that URI is in the authored unit
 
I next note that resources such as Web pages contain references to
further, subsidiary resources that may or may not be accessed in order
to
render the content. Examples include style sheets, images, RDF
metadata, etc. There are other resources referred to, e.g., links,
that may or may not be accessed. Which of these are deemed to be
"within" the authored unit under the proposed definition?

I think these examples are sufficient to show where the ambiguities lie.


GV2 - all of the authored units that are within the authored unit at that
URI are included. 



 > 
 > Regarding second comment -   I'm not sure I understand your comment.
Your
 > comment seems to agree with the bulk of what was posted. 
 > 
 > Or were you referring to the ATAG question.  
 > The idea was -- if you use an author tool (e.g. a comment tool) that
 > essentially forces you to create accessible content -- then could you
assume
 > accessible content.   However we questioned that that would work because
we
 > don't know how you can force accessible content (other than making it all
 > simple text -- but that is only good for a short comment and even then
only
 > at level 1).   If you were just agreeing with that skepticism than I
 > understand.   And you are on the same page as the group.  If you see
 > something else - then please post again to expand.  

Yes, I agree with that scepticism. If content isn't subjected to
sufficient machine/human testing to confirm that it conforms, then
there is no basis for making a conformance claim with respect to it. I
doubt that any automated procedure can serve as a satisfactory
conformance test.

So where does this leave us? Either we say that aggregated content
which doesn't conform can legitimately be scoped out by the author, in
which case we need to allow the author to specify the precise scope of
conformnace claims, or we conclude that no larger unit containing
non-conformant aggregated content can be subject to a conformance
claim, because it contains content that hasn't been created in ways
that yield high confidence in its conformance. If we took the first
option we would need to allow the author to give explict statements in
the conformance claim saying that certain content was out of scope.

Does this help to clarify my comments?
GV: Yes

GV3 - we were not allowing one to scope out authored units within an
authored unit.  If they don't have an access claim then you can't make an
access claim on the parent.  (at least that is what we were proposing for
discussion.  Everything else looked invalid to us)

Received on Thursday, 15 July 2004 01:33:32 UTC