datatype conformance and processing requirements are very vague

> Property: datatype
>
> Datatype defines the format type of an element.

Why is this needed as a global property? Outside a data entry widget,  
XSD datatypes don't seem to make sense:

string: Not specific. Pointless to declare.

boolean: Surely this isn't used in prose.

decimal, float, double: Surely AT should be able to recognize and read  
numbers without markup and according to the convention of the natural  
language of the page (instead of requiring the use of an English- 
biased format).

duration: Isn't this too specialized?

dateTime, time, date, gYearMonth, gYear, gMonthDay, gDay, gMonth: It  
seems like a bad idea to inflict the computer-oriented nature of these  
formats to sighted users as part of the visible page content. When  
there's a need to show a date or time in prose so that it is both  
formatted for sighted readers according to locale-specific conventions  
and to make it also machine-parseable for microformat and  
accessibility use, using the HTML 5 <time> element seems much better  
than <span aria-datatype='xsd:dateTime'>. I think implementor time  
would be better spent on exposing HTML 5 <time> to AT than on  
implementing aria-datatype.

hexBinary, base64Binary, QName, NOTATION: Surely these don't belong in  
accessible prose.

anyURI: URIs should be links.

> Datatype should be a qname that refer to an XML Schema Datatypes  
> [XSD] defined type.

The prose says that the value of aria-datatype is a qname but the  
table says it is a string. text/html, as currently implemented,  
doesn't provide a namespace mapping context, so there's nothing to  
resolve a qname against. Since ARIA will, with all likelihood, be used  
most often with text/html, making the value a qname seems like a bad  
idea.

> For example, a datatype may be xsd:integer.

If there's an attribute aria-datatype='xsd:integer', what are the  
document conformance requirements and what are the UA conformance  
requirements? What should a UA do with it?

> The author may also reference their own custom datatypes as long as  
> they are simple types.

How can a conformance checker tell whether a custom datatype is a  
simple type? What are the UA/AT processing requirements for custom  
datatypes? How are implementations expected to interoperate when  
custom datatypes are used?

> Clearly XSD base types are simpler for the user agent to understand.

Not without processing requirements.

Besides, introducing an XSD dependency in browsers seems like a bad  
idea given that it is recognized in XML circles that XSD is in a bad  
spec category. Quoting Michael Champion (from the Microsoft XML Team):  
"I think the reality is that lots of people flipped the Bozo Bit on  
the XSD spec in 1999-2000."
http://lists.xml.org/archives/xml-dev/200602/msg00061.html

Experiences voiced by various XSD *vendors* in a W3C workshop point to  
a conclusion that the XSD spec does not lead to interoperable  
implementations.
http://www.w3.org/2005/03/xml-schema-user-program.html
The papers are available as a single zip file:
http://www.w3.org/2005/05/25-schema/all.zip

(Granted, those comments are about XSD as a whole. But still.)

> Datatype applies to the content of an element, e.g., the value of an  
> input element that the user could change.

This case makes more sense that making aria-datatype a global  
property. In the input widget case, the reasonable XSD datatypes are  
the numeric and temporal types. Unfortunately, in XSD, those datatypes  
permit a lot of syntactic variability for no good reason, which makes  
them scripting-unfriendly. That is, if the AT is supposed to generate  
strings that are only guaranteed to match the lexical format specified  
in XSD, there are so many syntactic possibilities that it is  
unreasonable to expect JavaScript writers to deal with all the  
possibilities.

Web Forms 2.0 defines a set of form-relevant datatypes whose syntax  
has carefully been crafted to work with JavaScript and the native  
facilities of various server-side programming languages. To make it  
easier for scripters to process values and to harmonize datatypes in  
order to facilitate migration to HTML5 native forms, I suggest  
adopting the Web Forms 2.0 datatypes instead of the XSD datatypes.

If it is too late to change the datatype names for numbers and dates,  
please consider keeping the XSD names but requiring that whenever UA/ 
AT updates a value with a generated number or date, that string has to  
conform to the more constrained Web Forms 2.0 syntax even if it were  
labeled as the corresponding XSD type. (It should be safe to get rid  
of hexBinary, base64Binary, QName, NOTATION and boolean in any case.)

> This can facilitate automatic validation of user input.

That's a vague statement. Please define what piece of software is to  
perform input validation and how.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Tuesday, 25 March 2008 10:30:09 UTC