W3C home > Mailing lists > Public > public-xhtml2@w3.org > August 2008

Re: (PFWG) ACTION-211 Query re: SVG Request for @order for Access Module

From: Doug Schepers <schepers@w3.org>
Date: Tue, 12 Aug 2008 03:07:49 -0400
Message-ID: <48A136C5.6090906@w3.org>
To: Tina Holmboe <tina@greytower.net>
Cc: Shane McCarron <shane@aptest.com>, "Gregory J. Rosmaita" <oedipus@hicom.net>, w3c-wai-pf@w3.org, public-xhtml2@w3.org, w3c-wai-ua@w3.org, public-svg-wg@w3.org, wai-liaison@w3.org

Hi, Tina-

Tina Holmboe wrote (on 8/11/08 6:32 PM):
>
>   Authoring documents which violate agreed upon grammars will have
>   unpredictable consequences. We certainly don't need to send the
>   message that this is a desirable thing. Saying, clearly, that if one
>   do then things Might Just Break, is the pragmatic way forward.

The consequences (or, in more neutral terms, outcome) need not be 
undefined.  When a common circumstance can easily be quantified, 
defining a behavior for it is more pragmatic than not doing so.

The case of duplicate ids is something that occurs quite frequently when 
documents are merged, especially automatically.  There is no clear 
solution to this problem (though I agree it is a problem).  Figuring out 
how to fix that occurrence in a systematic way would be a bigger boon 
than simply assuming it doesn't.  Maybe someone should make a spec for a 
method that inserts strings into the document, like innerHTML(), but 
which also identifies conflicting ids and either throws an exception or 
"repairs" them by concatenating an iterated number on the id value. 
(Note: it's probably not that easy, because any scripts that come with 
the new content might expect the previous id...)

In the meantime, I don't see a problem with dealing with the problem as 
it exists today.


>   We're working on an XHTML standard 

The <access> element is of broad applicability, and is needed in more 
than just XHTML.  The SVG WG spent time and energy reviewing the spec 
because we intend to introduce it into SVG, and want to have 
interoperable behavior for the good of users, authors, and implementors. 
  Please keep us in mind as a consumer of your specifications.


> - not a possible-somewhere-something
>   future one. A standard which is a moving target, either in terms on
>   what is decided, or what multitude of possible situations that may or
>   may not occur that it tries to cover, is not worth the paper upon which
>   it is written. 

All standards are moving targets.  The best we can do is capture a 
useful current snapshot and hope we've future-proofed adequately enough 
to get us by until the next version of the spec.  It's silly to try to 
imagine and account for every foreseeable complication, but it's equally 
silly to ignore known and common ones.

But I'm not trying to engage in a philosophical debate, merely to 
suggest a practical, pragmatic solution that, in my opinion, is more robust.


>   It might be that I too am out of sync with the WG. But I don't think
>   so.

Of course.  The XHTML2 WG has to follow its conscience in how it best 
serves its constituency.

Regards-
-Doug Schepers
W3C Team Contact, WebApps, SVG, and CDF
Received on Tuesday, 12 August 2008 07:08:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 23 February 2010 18:12:49 GMT