Aggregated comments from chaals #552
Description
/cc @chaals
https://lists.w3.org/Archives/Public/public-pfwg/2015May/0069.html
HTML comments: https://lists.w3.org/Archives/Public/public-pfwg/2015May/att-0069/CSVcomments.html
Here is a copy/paste of the textual content, see link for full HTML:
tabular data model
table annotations
[relevant to accessibility, possibly due to misunderstanding]
Section 4.2 includes
Annotations on a table may include:
titles or descriptions of the table �
rather than "may" best practice would suggest using "should"
names for Rows
[relevant to accessibility, substantive]
In Section 4.4 it would be helpful for accessibility in particular to allow an annotation for "human-readable name", or some such, for rows. In practice this might be a primary or secondary key field, or a combination of two or more cells in the row.
Note this is related to the issue raised in github by L�onie
missing image description
[relevant to accessibility, editorial]
In section 4.6 the image should have a longdesc. Here's a fragment you could use. Note that it is generally easier if you put each description in its own file, due to HTML not having good containment models for things you link to. But if you collect them, please put each in a container element which is the target of the longdesc link. I.e. for longdesc="foo#bar" the target should look like
>article id="bar">
h2>...
not
h2 id="bar">...
description of the tree image in section 4.6
The anyAtomicType (any) datatype breaks down into subtypes as follows:
anyURI
base64Binary (binary)
boolean
date
datetime (datetime), which can be sub-typed as a
dateTimeStamp
decimal, which can be sub-typed as an
integer, further classifiable as one of
long, which can be further defined as
int, even further describable as
short, with a subtype
byte
nonNegativeInteger, which can be further defined as one of
positiveInteger
unsignedLong, even further describable as
unsignedInt, with a subtype
unsignedShort, which has a further subtype
unsignedByte
or nonPositiveInteger with a subtype
negativeInteger
double (number)
duration which can be further sub-typed as a
dayTimeDuration or
yearMonthDuration
float
gDay
gMonth
gMonthDay
gYear
gYearMonth
hexBinary (binary)
QName
string, which can be sub-typed as one of
normalizedString, further classifiable as a
token, which can be further defined as one of
language
Name
NMtoken
xml
html
json
time
confusing, perhaps unnecessary constraint
The end of Section 5.1 has
If the user selects existing metadata files, implementations must not use metadata located through the link header (as described in section 5.3 Link Header), file-specific metadata (as described in section 5.4 Standard File Metadata) or directory-specific metadata (as described insection 5.5 Standard Directory Metadata).
This is a bit unclear. Does it mean that if a user somehow refers to a single metadata file provided as part of the source, as part of some option for processing implementations must not use any others? If that interpretation is correct it seems overly constrictive. It should be reasonable to refer to a given file as something to use in addition to others, or in place of a specified set of other sources.
bad example, perhaps unnecessary constraint
The example in Section 5.3 shows two linked metadata files, of which only one meets the constraint of having a type that is among those required to be processed. Yet an natural reading suggests the example is illustrating the constraint that only one file may be processed. Perhaps another applicable file-type should be added, or the document should clarify that other filetypes may be processed, or both.
In any event, it is unclear why there is a constraint that only one linked file will be processed.
Non-standard well-known location processing
In section 5.4 and 5.5 there are requirements for dealing with information in well-known locations. But there is no mention of the standard approach of using /.well-known/� as specified in RFC 5785. Why not?
Ordering significance
Section 6.2.3 implies that the ordering of options in the format is significant but does not say so. It should be explicit.
zeugma
[relevant to accessibility, editorial]
(Thanks. I always wanted to use that word for real)
Section 6.2.6 says "in the syntax and processed as defined by" which is quite difficult to parse. (Strictly speaking it is not necessarily an example of zeugma, but it resembles one at first glance)
This should be clarified, e.g. by rephrasing "with syntax and processing defined by"
Loose line endings
Why not say in section 7.3 that line endings should be CR+LF but may be LF, analagous to the approach used to nudge the Web toward UTF-8 without prohibiting other formats used in the real world?