W3C

List of comments on “Protocol for Web Description Resources (POWDER): Description Resources” (dated 8 September 2008)

Quick access to

There are 12 comments (sorted by their types, and the section they are about).

typo comments

Comment LC-2118: random src attribute
Commenter: Phil Archer <parcher@fosi.org> (archived message)
Context: in
Not assigned
Resolution status:

Just spotted that in the appendix to the DR doc [1] the label and
comment elements suggest that these take a src attribute -which they don't.

P

[1] http://www.w3.org/TR/2008/WD-powder-dr-20080815/#label
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2113: Stray ref
Commenter: Phil Archer <parcher@fosi.org> (archived message)
Context: in (example 4-5)
Not assigned
Resolution status:

My mini validator [1] has thrown up an error in example 4-5 of the DR
doc [2]. Line 6 includes a ref attribute - it should be src.

P

[1] http://keg.icra.org/cgi-bin/pdrvalidate.cgi
[2] http://www.w3.org/TR/2008/WD-powder-dr-20080815/#eg4-5
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2115: Typo in DR Doc summary table
Commenter: Phil Archer <parcher@fosi.org> (archived message)
Context: in (Appendix)
Not assigned
Resolution status:

Just working on building a POWDER Processor and I notice, following on from this conversation, that there's an error in the summary table in the DR doc [1] - it says that there must be exactly 1 descriptor set (unless there's a tagset). No, no no... you can have any number of descriptor sets.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2117
Commenter: Phil Archer <parcher@fosi.org> (archived message)
Context: in
Not assigned
Resolution status:

I just noticed that example 5.1 in the DR doc [1] has a minor typo -
there's an extra > at the end of the issuedby element.

The depressing aspect of which is that the validator [2] didn't pick
this up. (just when I was beginning to have a little faith in it. Ah
well...)

Phil.

[1] http://www.w3.org/TR/2008/WD-powder-dr-20080815/#eg5-1
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

substantive comments

Comment LC-2120
Commenter: Shadi Abou-Zahra <shadi@w3.org> (archived message)
Context: in
#1. Referring to technical standards for labeling, such as WCAG 2.0

We understand that the following type of code could be used to refer to
a technical standard that the POWDER label implies:

<descriptorset>
<acc:guidelines>WCAG 2.0</acc:guidelines>
<acc:level>AA</acc:level>
<displaytext>Everything on example.com is red and square>/displaytext>
<displayicon src="http://authority.example.org/icon.png" />
<typeof src="http://www.example.org/vocabulary#WCAG20-AA" />
<seealso src="http://www.w3.org/TR/WCAG20/" />
</descriptorset>

Comment: have you considered a specific property that can be used to
reference such as technical standard rather than "seealso"?
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2121
Commenter: Shadi Abou-Zahra <shadi@w3.org>
Context: in
#2. Referring to test reports to validate or justify the labels

We understand that the following type of code could be used to refer to
test reports, such as EARL reports that contain test results:

<attribution>
<issuedby src="http://www.example.com/company.rdf#me" />
<issued>2008-06-25T00:00:00</issued>
<supportedby src="http://validator.example.org/report.earl" />
</attribution>

Comment: have you considered a specific property that can be used to
reference such test reports rather than "supportedby"?
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2122
Commenter: Shadi Abou-Zahra <shadi@w3.org> (archived message)
Context: in
#2. Referring to test reports to validate or justify the labels

We understand that the following type of code could be used to refer to
test reports, such as EARL reports that contain test results:

<attribution>
<issuedby src="http://www.example.com/company.rdf#me" />
<issued>2008-06-25T00:00:00</issued>
<supportedby src="http://validator.example.org/report.earl" />
</attribution>

Comment: have you considered a specific property that can be used to
reference such test reports rather than "supportedby"?
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2123
Commenter: Shadi ABou-Zahra <shadi@w3.org> (archived message)
Context: in
#3. Methodology used for concluding claims and labels

In some cases an documented methodology is used to evaluate the
conformance of Web content to a technical standard. For example, the
Unified Web Evaluation Methodology (UWEM) is a publicly documented
evaluation methodology for Web accessibility (it evaluates conformance
to WCAG 1.0). We understand that also in this case the "seealso"
attribute is used to refer to such methodologies. Have you considered a
specific property to reference evaluation/conformance methodologies?
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2114
Commenter: <parcher@fosi.org> on behalf of Ivan Herman (archived message)
Context: in (Section 2)
Ivan H has been amending his Creative Commons/SW logo copyright example
to fit in with the LC drafts and I'm just looking at it now.

In one of his descriptor sets, Ivan has included two displaytext
elements. This is, I'm sure, an oversight, but looking at the doc [1] we
don't say that this is invalid - and the validator I'm working on
doesn't spot this. So we have two options I'd say:

1. Amend the text to make multiple display text (and displayicon)
elements invalid

2. Add a line to say that how a UA handles multiple display elements is
application-specific (it might display both or the first one, or the
last one or whatever)

[1] http://www.w3.org/TR/2008/WD-powder-dr-20080815/#operational

Phil.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2124
Commenter: Shadi ABou-Zahra <shadi@w3.org> (archived message)
Context: in
#4. Contact point or complaint mechanism for labels

Many labeling schemes require some form of contact point or complaint
mechanism, for example if an end-user feels that the claim is false or
that the label is otherwise misused. Often these complaint forms are
linked from the graphical icon on the Web pages. Have you considered a
specific property to supplement "displaytext" and "displayicon", that
provides a link to the feedback resource?
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2127
Commenter: Chaals <chaals@opera.com> (archived message)
Context: in
2. We believe that the Link header is likely to be formalised, as it is
implemented already and is not very complicated. Therefore we suggest that
this feature remain.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2111: rel = describedby
Commenter: Phil Archer <parcher@fosi.org> on behalf of Mark Nottingham (archived message)
Context: in (4.2)
whilst our use of HTTP Link is right in Mark's view, the
registration of rel="powder" probably isn't. Section 4.2 [2] of the
draft says:

"A Link relation is a way of indicating the semantics of a link. Link
relations are not format-specific, and MUST NOT specify a particular
format or media type that they are to be used with."

I was concerned about this since rel="powder" /does/ indicate a
particular format (i.e. POWDER). I raised this on the HTTP list and
Jonathan Rees replied [3] that he thought this referred to the origin of
the link, not its target. Mark said no - actually the intention is that
/neither/ end of the link should be format-specific - that's the job of
the MIME type.

I said that we were wary of trying to register a new MIME type - after
all, POWDER is either XML or RDF/OWL (semantic extension
notwithstanding) and that HTML Profile meant we didn't /need/ to
register either rel="powder" or a new MIME type. Well... that's true but
we are talking about registering the @rel type so that argument rather
loses potency!

Mark pointed me to a doc [4] that is an entry point for a description of
how we would register the POWDER Media type which actually looks pretty
simple - being in a W3C Rec document means that IETF is likely to agree
to the new type with little delay.

To get to the point, Mark's recommendation is that we

1. Use a more generic @rel type of describedby (something other groups
want as well btw)

2. Register a POWDER-specific Media type.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Add a comment.


Developed and maintained by Dominique Hazaël-Massieux (dom@w3.org).
$Id: index.html,v 1.1 2017/08/11 06:44:46 dom Exp $
Please send bug reports and request for enhancements to w3t-sys.org