Re: Core Presentation Characteristics

Roger,

It's taken me a while to get round to looking at this;  my apologies for 
late comments.

Overall, I find the requirements and scope presented are clear and 
sensible.  I'm pleased to see the requirements distilled and clearly 
stated.  The length of this message shouldn't be taken as a measure of 
disagreement -- most of my points are small issues in the overall scheme.

I think there's one important requirement missing (from section 4.1), which 
I might call monotonicity.  By this, I mean that the capability described 
by an attribute, or the semantics otherwise associated with an attribute, 
must not be invalidated by the inclusion of other attributes (that can 
validly be specified).   Another way of saying this should be that the 
meaning of an attribute must be independent of any other attributes that 
are present:  it is OK for further attributes to *refine* the meaning of an 
attribute (as happens some of the IETF attributes dealing with colour for 
Internet fax, see RFC2534 [1] and RFC2879 [2]), but the original meaning 
must not be modified.

A rationale for this is that an agent should be able to use those parts of 
a feature description that it understands, and ignore the rest, without 
risk of arriving at an incorrect assessment of the device's 
characteristics.  Another reason is to try and avoid having multiple ways 
to describe the same capability (this is aided if features are independent 
and non-conflicting).

I'd commend RFC2534 to the group as a strong starting point, as it was 
precisely an attempt to define a simple set of core features applicable to 
a wide range of web browsing activities.

And some comments to specific text:

...

Section 3:

Signed integer as type of display size in IETF media features -- this was 
(IIRC) simply because CONNEG doesn't define an  unsigned integer, and there 
was no intent that the display could actually be negative. The spec is 
quite explicit that the measure is in pixels.

...

Section 4.1:

[[
An attribute may have a value that is not a simple value when:

     * CPCR07 the option of expressing a compound value for an attribute, 
such as a set or sequence, is theoretically possible.
]]

I would suggest that any compound values proposed be carefully considered 
to see if they cannot be reduced into a number of atomic values -- in the 
long run, I believe this will result in descriptions that are easier to use 
for the purposes of content adaptation.

...

Section 4.2:
[[
CPCR09 - Reuse: The overall set of Core Presentation Characteristics must 
be defined as:

     * one or more XML schemas (with URI)
     * and/or one or more RDF schemas (with URI)
     * and/or one or more CC/PP schemas (with URI)

in order to allow unambiguous reuse of the core attributes in different 
application contexts.
]]

I think you maybe should decide whether you mean AND or OR in the 
above.  Maybe answering that question is for the core feature design 
team?  If there is genuine need for more than schema description, then I 
suggest they probably should always be provided for all feature 
specifications.  (I think one of the practical benefits of the core feature 
descriptions should be an example to others about how to specify them.)

...

Section 4.2:

[[
CPCR11 - Modularity: The core attributes must be grouped into related 
subsets to allow reuse of selected subsets in defining future vocabularies.
]]

I don't see why this grouping is a *requirement*.  What I think is a 
requirement is that actual profiles/descriptions can mix-and-match from 
different vocabularies.

...

Section 4.2:

[[
CPCR12 - Versioning: The Core Presentation Characteristics Recommendation 
should make proposals that address how adding, removing or changing 
attributes in a vocabulary should be handled in order to:

     * clearly identify the applicable attribute definition in any instance
     * maximize the backward and forward compatibility with existing and 
future applications
]]

Good luck!  While this is clearly desirable, it seems to be a tougher 
problem than at first seems (unless you can find ways of constraining the 
versioning requirements).  Mainly, I think you need to be clear that this 
is not a necessarily requirement for a powerful versioning mechanism, but 
simply that the issue of evolving feature vocabularies needs to be considered.

...

Section 4.3:

[[
CPCR14 - Common Adaptation: The Core Presentation Characteristics must be 
useful for common adaptation tasks.
]]

This reminds me of an old adage:  simple things should be easy, and complex 
things should be possible.

In this context:
   s/simple/common/
   s/complex/obscure/
?

...

Section 4.3:

[[
CPCR16 - Separation of input and output: The Core Presentation 
Characteristics should allow the author to specify whether an attribute is 
applicable to output, input, or both.
]]

This requirement seems misplaced (doesn't it belong in 4.1?), and in view 
of the requirement for well-defined semantics (CPCR04), possibly redundant.

...

Section 5

[[
One use case is shown as the definition of a document profile. It is 
intended that the attributes associated with a document could be used as 
part of content negotiation to match the document to a request for a 
specific delivery context. Again, it is not the purpose of the proposed 
recommendation to specify a particular content negotiation mechanism. 
However, the value of using comparable attributes in a document request and 
in a document profile should be obvious.
]]

Personally, I'd like to see this asserted more strongly.  Cf. RFC 2703 [3], 
whose goals strongly favour a uniform framework for expressing features of 
all parties involved, thus providing a basis for matching document features 
againt receiver capabilities.   [Later, I see you note this in your use 
case 5.4!]

...

#g
--

[1] http://www.rfc-editor.org/rfc/rfc2534.txt

[2] http://www.rfc-editor.org/rfc/rfc2879.txt

[3] http://www.rfc-editor.org/rfc/rfc2703.txt


At 11:10 04/06/03 +0100, Roger Gimson wrote:
>Hello Graham,
>
>Previously you commented on the W3C Device Independence WG proposals for
>Core Presentation Attributes (now renamed Characteristics).
>
>We have published a new working draft, which takes into account some of 
>your suggestions:
>
>Core Presentation Characteristics: Requirements and Use Cases
>     http://www.w3.org/TR/2003/WD-cpc-req-20030510/
>
>and would welcome any further comments you might have.
>
>We intend to start work on a W3C recommendation track to meet these
>requirements, but would like to focus on a small core of highly useful
>characteristics to begin with. Suggestions for what should be included in
>this initial core would also be welcome. We will, of course, be relating
>them to existing vocabularies such as CONNEG Media Features.
>
>Regards,
>
>Roger Gimson
>
>--
>roger_gimson@hpl.hp.com | HP Labs, Bristol BS34 8QZ, UK | +44 117-312-8167
>

-------------------
Graham Klyne
<GK@NineByNine.org>
PGP: 0FAA 69FF C083 000B A2E9  A131 01B9 1C7A DBCA CB5E

Received on Monday, 16 June 2003 12:47:47 UTC