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"
[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"
[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
[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>...>h2 id="bar">...The anyAtomicType (any) datatype breaks down into subtypes as follows:
anyURIbase64Binary (binary)booleandatedatetime (datetime), which can be sub-typed as a
dateTimeStampdecimal, 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 bytenonNegativeInteger, which can be further defined as one of
positiveIntegerunsignedLong, even further describable as
unsignedInt, with a subtype unsignedShort, which has a further subtype
unsignedBytenonPositiveInteger with a subtype
negativeIntegerdouble (number)duration which can be further sub-typed as a
dayTimeDuration oryearMonthDurationfloatgDaygMonthgMonthDaygYeargYearMonthhexBinary (binary)QNamestring, which can be sub-typed as one of
normalizedString, further classifiable as a
token, which can be further defined as one of
languageNameNMtokenxmlThe 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.
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.
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?
Section 6.2.3 implies that the ordering of options in the format is significant but does not say so. It should be explicit.
[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"
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?