RE : Cc/pp S&V conformance section

Hello Lynne,

> However, I'm still having trouble with the clarity of 
> non-validating consumers.
> 
> 1.  The 2 categories are not written in the same style - they 
> should both 
> start the same (e.g., A consumer is a... or The behavior 
> of....). 
> 2.  As written, it is possible for a non-validating 
> consumer to reject all 
> non-conformant CC/PP documents, since the behaviour is not 
> specified - thus 
> it would be a validating consumer.
> (behaviour is not the US spelling - behavior)

Well, this is true : a ccpp consumer rejecting all non-conformant
profiles may decide to be in the non-validating section. Being a
validating consumer means that you are doing more work than the snd
category. So if you can apply for the 1st category, then you may decide
that you would prefer to stay in the lower category but i've hard time
understanding the rationale behind such a decision.
The 2 categories are not mutually exclusive. Being a validating consumer
means that the product would have more constraints as we have to
evaluate the behaviour for non-conformant profile.

> 3. Do you really need #2, since a validating consumer rejects 
> non-conformant documents, then anything else is 
> non-validating. 

This is a good question. We already discussed it many times in the
group. We specifically want to say that it is not required to be
validating to claim that you are conformant to the spec. Thus we have to
distinguish between the 2 cases no ?

> 4.  If #2 is the inverse of #1 then I think 
> that what you had before was 
> clearer - basically, a consumer is non-validating if it accepts any 
> non-conformant CC/PP document.

No, this is not the case and that's why we changed the wording to make
it clearer that #2 is not the inverse of #1

> 5. Suggestion for #2:  A consumer is a CC/PP non-validation 
> conformant 
> consumer if it accepts any non-conformant CC/PP document.

That's not the case. Definetly a non-validating consumer is a consumer
for which we have no requirement on its behaviour regarding
non-conformant profiles.

So is it now clearer ?

Thanks for all your comments
Steph 
> 
> 
> 
> 
> 
> 
> At 08:33 PM 7/24/2003, Luu Tran wrote:
> >Hi Lynne,
> >
> >Thank you for your comments [1] on the CC/PP S&V TR.  The DIWG has
> >prepared an updated draft [2] which we believe addresses your points:
> >
> >>1. What is meant by 'extracts appropriate information'.  Since
> >>'appropriate' is vague and subjective, can this be made 
> more specific?
> >
> >Unfortunately, what information a producer extracts is very 
> application
> >specific.  The best we could do is "extracts CC/PP information".
> >
> >>2. It may be clearer to be more explicit regarding a consumer's 
> >>support
> >>(or non support) for Appendix B.  If I understand 
> correctly, support for 
> >>the RDF Schema is mandatory for validating consumers.
> >
> >What we mean is that consumers need not be schema-aware 
> processors in 
> >the
> >sense that they can be configured with the schema format given.  The 
> >information contained within the schema must be understood by the 
> >consumer, but the format used to configure the consumer can 
> be application 
> >specific.
> >
> >>3. Editorial:  Change 'all' to 'any' in non-validating: A 
> consumer is 
> >>a
> >>CC/PP conformant non-validating consumer when it does not 
> reject all 
> >>non-conformant CC/PP documents.
> >
> >We've changed the definition to avoid both terms since we 
> weren't happy
> >with either.
> >
> >>4. Comments on 5.5.2 Well-formed.
> >>Add to the list of information to be included in a claim, the name
> >>(identify) of the implementation to which the claim is 
> being made. Also, 
> >>a version, date, or other identifier should be included to uniquely 
> >>identify the implementation.
> >
> >We've added this.
> >
> >Please let us know if the new draft looks ok.
> >
> >Thanks,
> >Luu
> >
> >[1]http://lists.w3.org/Archives/Member/w3c-di-wg/2003Jul/0103.html
> >[2]http://www.w3.org/Mobile/CCPP/Group/PR/PR-CCPP-struct-voca
> b-20030723
> >/
> >
> >
>

Received on Tuesday, 29 July 2003 03:46:44 UTC