Re: Namespaces and the Web (was: ARIA States and Properties Meeting)

On Oct 24, 2007, at 22:35, Doug Schepers wrote:

> Henri Sivonen wrote (on 10/24/2007 7:56 AM):
>>> This means that either ARIA attributes have to be part of the  
>>> core of XHTML, SVG, etc.,
>> No, the specs that define XHTML and SVG could make a normative  
>> reference to an ARIA spec and refrain from defining aria-*  
>> attributes on their own. There is no technical reason why spec  
>> organization and division into namespaces (in the sense of  
>> Namespaces in XML) would have to be the same.
>
> Incorrect.  There are technical reasons, just not ones you feel are  
> important.  There is a difference.

There's precedent for organizing specs boundaries and namespace  
boundaries differently. The Ruby spec defines additions to the XHTML  
1.x namespace. Yet, Ruby is organized into a separate specification  
document. Thus, one namespace can have stuff defined for it in one  
than one spec document. My understanding is that SVG Full 1.2 is  
supposed to be just the diffs from SVG 1.2 Tiny, so SVG itself shows  
that you don't need a new namespace when you split a spec.

> Without namespacing, there is no way to validate SVG content that  
> uses ARIA, because at best, SVG UAs will simply ignore the extra  
> attribute.

First, that has nothing to do with *specification* organization. If  
validation is understood in the traditional schema language-based  
sense, it has something to do with *schema* organization. Insisting  
that specification organization has to match schema organization is  
an artificial constraint.

I'm not sure what you mean by "no way to validate". If you meant  
making the ARIA attributes not cause an SVG document to be deemed  
invalid according to a RELAX NG schema, the goal can be achieved  
regardless of naming. Either of the following would work:
  * Listing the aria-* attributes in the RELAX NG schema. This list  
can be put in a separate schema file.
  * Filtering the aria-* attributes out of the infoset prior to RELAX  
NG validation.

Granted, with namespaces it would be easier to put a wild card in  
RELAX NG or to use NVDL to do the filtering. (I'm picking up these  
languages from our earlier IRC discussion.) Still, it is incorrect to  
claim that the aria-* naming convention would prevent validation.  
Moreover, I think it is wrong to inflict complexity on user agents  
and authoring due to limitations of schema languages. Designing a Web  
language to make sense for authors and for browser implementations is  
much more important than making it fit RELAX NG or NVDL nicer.  
Besides, the approach of listing the ARIA attributes in the RELAX NG  
schema is really easy and can be confined to one include file.

If you meant actually checking that the ARIA attributes conform to  
ARIA instead of merely getting them out of the way of validating the  
non-ARIA parts of an SVG doc, the validation mechanism would need to  
know about ARIA either way.

> You have argued that schema- and DTD-based validation can't  
> indicate all violations of a spec, which is true; but it can  
> indicate a *useful* subset of those violations.

Yes, I have argued that but I don't see its relevance to spec  
organization vs. organizing stuff into namespaces.

> It is useful for an author to know that they misspelled an  
> attribute name; it is mysterious to them when they don't get the  
> expected results, with no way to know why without scanning each  
> character of code. Validation provides that.

Yes, but if you use a RELAX NG wild card or NVDL to merely ignore  
ARIA attributes, they aren't checked. If you are checking them, you  
need to check them regardless of the naming convention.

All namespaces (in the Namespaces in XML sense) buy you is the  
ability to separate concerns by filtering the infoset using an NVDL  
engine instead of e.g. a custom SAX filter. But then again, you could  
also separate concerns inside a RELAX NG schema by merely putting the  
ARIA stuff in a separate include file.

> It is useful for an author to know that they assigned the  
> 'multiselectable' property or 'pressed' state to a 'radio' role,  
> and that those aren't supported for that role type.  Validation  
> provides that.

Yes, but you can express such co-occurrence constraints in e.g. RELAX  
NG and Schematron regardless of whether the naming scheme is aaa:foo  
or aria-foo.

> SVG (or someone) could write a schema that merges SVG's and ARIA's  
> schemas, but that goes pear-shaped when any changes or extensions  
> of either language come out, and it only works for those 2  
> languages for that period of time.

If ARIA is updated out-of-sync with SVG, does it really matter if you  
need to swap a RELAX NG include file or a schema that has been  
integrated using NVDL?

> Namespaces solves that problem in a way that works for all  
> languages for any time.

No it doesn't. If you have one schema for SVG and another for ARIA,  
you still need to update a schema when a spec is updated.

> It doesn't require someone who understands the intricacies of  
> schemae to combine two languages;

I would hope we could count on there existing at least one person who  
is interested enough in SVG and ARIA to take the time to grok schemas  
and update them as open source for other to use. Every schema user  
shouldn't have to integrate schemas on his/her own anyway.

> it requires only a simple declaration and prefix scheme.

If you put ARIA stuff in aria.rnc and included it from the SVG  
schema, ARIA folks could publish a replacement aria.rnc and schema  
users would just overwrite the old include file with it.

> In short, there are technical reasons (and even reasons of ease of  
> authoring).  Whether they are sufficient to hold sway over other  
> factors is another matter, but it is untrue to mistakenly claim  
> there are not.

I didn't see any technical reasons for coupling spec organization  
with organization into namespaces in the Namespaces in XML sense. I  
didn't see convincing reasons for coupling schema organization with  
spec organization, either.

>>> one of which is only available to official standards, because it  
>>> cannot guarantee global uniqueness otherwise.
>> Global uniqueness is a red herring. Collisions with pre-existing  
>> HTML and SVG attributes are the real technical concern for *Web*  
>> accessibility. aria-* does not collide with pre-existing HTML or  
>> SVG attributes, so collisions are not a problem with the aria-*  
>> scheme. Collisions with attributes from *theoretical* *non-Web*  
>> languages aren't a real technical concern for enabling *Web*  
>> accessibility--just like making the id attribute in no namespace  
>> have ID semantics would have worked just fine for Web languages  
>> and xml:id addresses a theoretical non-Web problem.
>> When developing specs for the Web, we shouldn't let theoretical  
>> non-Web concerns add complexity.
>
> Do you consider set-top boxes as part of the Web?  What if they  
> have network capability?  Internet capability?

I consider set-top boxes Web-relevant if they have Internet  
connectivity and run a browser that can access the Web in general-- 
not just pages authored for set-top boxes. For example, a Web-capable  
browser is available for Nintendo Wii. (I'd also consider a set-top  
box Web relevant if it had an X server in it and the Web-capable  
browser was run on a remote computer with the X display on the set- 
top box.)

If a set-top box cannot be used to access general Web pages, then no,  
I don't consider the set-top box Web-relevant.

> Do you consider mobile phones as part of the Web?

I consider mobile phones Web-relevant if they have Internet  
connectivity and run a browser that can access the Web in general-- 
not just pages authored for mobile phones. My current phone shipped  
with a Web-capable browser and I've even installed another Web- 
capable browser on it. My old phone did not ship with a Web-relevant  
browser. It came with a browser that claimed to support XHTML-MP but  
that demonstratably didn't even have a conforming XML processor in  
it. However, I was able to make my old phone Web-relevant by  
installing a display client for a remotely running Web-capable browser.

If a mobile phone cannot be used to access general Web pages, then  
no, I don't consider the mobile phone Web-relevant and as a user I  
don't want to buy such a phone.

> If you answer "no", I think you are being short-sighted.  If you  
> answer "yes", then you have to acknowledge that it's not  
> "theoretical" or "non-Web".

I don't follow.

> There are already many UAs for both these classes of devices, and  
> they do mix other XML syntaces into their content, and any answer  
> that we arrive at must include them.  As I understand the charter  
> of this group, it intends to make an XML serialization of HTML5,  
> and would like to set that as the baseline for future XHTML work.   
> This is not theoretical, and it is not non-Web.  Those are  
> rhetorical arguments that are of little bearing in a technical  
> discussion.

Do those browsers add aria-* attributes to XHTML or SVG on their own  
in a way that would actually conflict with the proposed addition of  
aria-* attributes. Could you please name names of Web-relevant  
browsers with which the aria-* proposal would be incompatible?

> I am *not* insisting that we have ARIA in its own namespace; I am  
> insisting that we talk about it using facts, not political positions.

I'm all for using facts over politics.

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

Received on Wednesday, 24 October 2007 22:37:28 UTC