@role in SVG

Hi, SVG community-

The SVG WG likes the functionality and extensibility that
the 'role 
attribute affords, and the potential for increased
accessibility, so we 
do want to include it in SVG (and to see it implemented as
soon as 
possible, so authors can use it right away).  We've talked
about how 
best to do so, and we'd like to solicit opinions from
interested 
parties, including the other Working Groups involved,
implementors, and 
authors.

To summarize the options, we can include the 'role'
attribute in the 
XHTML namespace, or as a native null-namespace attribute. 
Each approach 
has benefits and problems.

1) XHTML Namespace
<svg
   xmlns="http://www.w3.org/20
00/svg"
   xmlnslink=
"http://www.w3.org/
1999/xlink"
   xmlnshtml=
"http://www.w3.org/
1999/xhtml"
   xmlns:aaa="http://www.w3
.org/2005/07/aaa">
   <g xhtml:role="checkbox"
aaa:checked="true">...</g>
</svg>

Pros:
* does not require any changes to SVG syntax...
automatically available 
via XML's innate extensibility mechanism
* conforms to current version of the Role spec [1]

Cons:
* is slightly harder to author (requires working knowledge
of 
namespaces, or good voodoo skills)
* differs in syntax from how it would work in XHTML and
HTML5 (so may be 
harder to learn, and possibly to implement)
* more verbose


2) Native Non-Namespaced Attribute
<svg
   xmlns="http://www.w3.org/20
00/svg"
   xmlnslink=
"http://www.w3.org/
1999/xlink"
   xmlns:aaa="http://www.w3
.org/2005/07/aaa">
   <g role="checkbox"
aaa:checked="true">...</g>
</svg>


Pros:
* more similar in syntax to XHTML and HTML5 (easier to use
and maybe 
implement)
* less verbose
* maybe less error-prone for authoring, mash-ups, compound
documents

Cons:
* would require a change to SVG (see details below)
* would require change to Role spec to allow "host
language" (SVG) to 
incorporate it into its own language (note that there is
precedent for 
this in the previous version of the Role spec [2], not sure
why it was 
changed)

Neutral:
* still requires knowledge of namespaces, but only for
including ARIA


Changes Required to SVG Specifications

As mentioned, including 'role' via the XHTML namespace
requires no 
changes to SVG (though would benefit from a Note on the
details), but I 
understand that some might not find it the cleanest or most

author-friendly solution.  So, the SVG WG is open to include
it directly 
in the SVG language, if that's the solution the community
feels is best 
(and if it is allowed by the Role spec).

If we are to include it in the language, just how we do so
depends on 
which version of SVG.  We can't add it as a feature to SVG
1.1 or before 
(adding features that change conformance to a past version
is not 
allowed in the W3C Process), but we could do so for SVG 1.2
Full with 
few or no problems.  There is a chance we could do it for
SVG 1.2 Tiny, 
because it's not yet in PR, but adding features at this late
stage might 
not sit well with the standards community (though the
implementors on 
the WG assure us that merely adding an attribute is
trivial).  We would 
like to do it, but not if it's seen as unacceptable by the
standards 
community.

Another factor is that we don't want to be dependent upon
the Role 
Attribute  and the CURIE specs for our Rec-Track exit
criteria.  But 
neither do we want to specify it separately (or differently)
than that 
spec.  A possible solution is that, for SVG 1.2 Tiny, we
would include 
it as an attribute whose value is a space-separated list of
strings, and 
when the Role and CURIE specs are more mature, in the SVG
1.2 Full 
timeframe, we would change the specification of 'role' to
refer to those 
specs.  This is not a very clean solution, but it would get
the 'role' 
attribute out there, and let authors create content now in
as easy a 
manner as possible.


Changes Required to Role Attribute Specification

As mentioned before, for this to happen, the Role Attribute
spec would 
need to explicitly allow SVG to do it.  We'd like feedback
from the 
XHTML2 WG on this.  It would be ideal, perhaps, if the Role
spec 
optionally allowed the values to be strings instead of
CURIEs (as 
specified in a host language), but that may be a bridge too
far.


Prompt feedback on this issue would be greatly appreciated.


[1] http://www.w3.org/TR
/xhtml-role/
[2] http://www.w3.org/TR/2006/WD-xhtml-role-20060725/#docco
nf

Regards-
-Doug Schepers
W3C Staff Contact, SVG, CDF, and WebAPI

Hi, Jonathan-

Please define "naive users".  As I said, if you
wish to represent a 
constituency, you will have to stop using such vague terms,
or we cannot 
begin to answer your questions.

Regards-
-Doug Schepers
W3C Staff Contact, SVG, CDF, and WebAPI

~:'' ありがとうございました。 wrote (on
10/10/2007 2:24 AM):
> as I previously mentioned it appears that there has
been no response 
> from any naive users.
> 
> It's my opinion, already expressed that this change has
not been 
> presented in a means presentable to such an audience.
> 
> I am for instance not able to ask non-expert audiences
for their opinion 
> to feed back into discussions.
> 
> I do not consider it sufficient that the WG is excited
by this possibility.
> 
> Rather than imagining the pros and cons.
> Please take the opportunity to ask.
> 
> regards
> 
> Jonathan Chetwynd
> Accessibility Consultant on Media Literacy and the
Internet

On Oct 10, 2007, at 03:59, Doug Schepers wrote:

> 1) XHTML Namespace
> <svg
>   xmlns="http://www.w3.org/20
00/svg"
>   xmlnslink=
"http://www.w3.org/
1999/xlink"
>   xmlnshtml=
"http://www.w3.org/
1999/xhtml"
>   xmlns:aaa="http://www.w3
.org/2005/07/aaa">
>   <g xhtml:role="checkbox"
aaa:checked="true">...</g>
> </svg>

> 2) Native Non-Namespaced Attribute
> <svg
>   xmlns="http://www.w3.org/20
00/svg"
>   xmlnslink=
"http://www.w3.org/
1999/xlink"
>   xmlns:aaa="http://www.w3
.org/2005/07/aaa">
>   <g role="checkbox"
aaa:checked="true">...</g>
> </svg>

I'm curious why a third way isn't mentioned:
3) Non-Namespaced Attributes for both role and
states/properties with  
the latter prefixed with "aria-" (and no qNames in
content but opaque  
strings):
<svg
   xmlns="http://www.w3.org/20
00/svg"
   xmlnslink=
"http://www.w3.
org/1999/xlink">
   <g role="checkbox"
aria-checked="true">...</g>
</svg>

Pros:
  * Matches what has recently been proposed for (X)HTML5 and
XUL.  
Good both for implementation and author skill portability.
  * Fewer namespaces to deal with (i.e. easier).
  * Copy-paste-friendly.
  * DOM-friendly. (qNames in content are *bad* in the DOM.)
  * Not a chameleon namespace per se. The attributes would
be in no  
namespace in XHTML5, SVG and XUL.
  * Semantics and processing can still be imported by
normative  
reference from wherever they get defined for HTML5. No need
to spec  
all this in the SVG spec.

Cons:
  * Not what the WAI PFWG draft currently says.
  * Unorthodox in terms of XML architecture.

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

Hi, Henri-

Thanks for the reply.  (I'm particularly glad to have the
feedback of 
the HTML 5 guys on this, since we want to coordinate with
you as much as 
possible.)

Henri Sivonen wrote (on 10/10/2007 11:21 AM):
> 
> I'm curious why a third way isn't mentioned:
> 3) Non-Namespaced Attributes for both role and
states/properties with 
> the latter prefixed with "aria-" (and no
qNames in content but opaque 
> strings):
> <svg
>   xmlns="http://www.w3.org/20
00/svg"
>   xmlnslink=
"http://www.w3.
org/1999/xlink">
>   <g role="checkbox"
aria-checked="true">...</g>
> </svg>

That's an orthogonal issue to how role is integrated into
SVG.  It's 
worth talking about, but I think it can be addressed as a
separate 
issue.  role in SVG will likely have more uses than
accessibility.

Comments inline:

> Pros:
>  * Matches what has recently been proposed for (X)HTML5
and XUL. Good 
> both for implementation and author skill portability.

I agree that having a shared syntax is a worthwhile goal,
for the 
reasons you mention.  Since there have been no technical
decisions yet 
made for HTML5, it's hard to know what the status of that
proposal is, 
especially since it is not quite in line with the XHTML Role
Attribute 
Module spec.  Is there some general consensus on the
proposal?


>  * Fewer namespaces to deal with (i.e. easier).

Once the author has to deal with namespaces, it's not
entirely clear 
that fewer namespaces is easier.  It is shorter, for sure.


>  * Copy-paste-friendly.

That goes hand in hand with shared syntax.  I will grant
that requiring 
NS declarations is slightly less friendly (requires copying
the 
NS-declaration as well as the target content that uses it),
but if we 
are aligned on syntax, it's just about as copy-paste
friendly either way.


>  * DOM-friendly. (qNames in content are *bad* in the
DOM.)

Can you elaborate on that?


>  * Not a chameleon namespace per se. The attributes
would be in no 
> namespace in XHTML5, SVG and XUL.

I don't think that inherently avoids the issue I raised,
that there may 
be potential interfaces implemented on the attribute in one
language and 
not the others (which raises the same problems as chameleon
namespaces, 
whether or not it's precisely the same).  The easiest
resolution to that 
issue is an agreement that the attribute is defined in one
mutually 
exclusive place, and that all changes are specified only in
that single 
specification.  (FWIW, I don't see this as a pro or con,
either way.)


>  * Semantics and processing can still be imported by
normative reference 
> from wherever they get defined for HTML5. No need to
spec all this in 
> the SVG spec.

Agreed.  But if it's going to be shared, and we know that
ahead of time, 
it would be far better to split out any semantics and
processing that we 
need in a separate document, and reference it from both
specs, with each 
language specifying only the language-specific aspects of
it.  (Again, 
this is not really a "pro", in that it doesn't
support either position, 
but it is something to be considered.)


> Cons:
>  * Not what the WAI PFWG draft currently says.

That spec could be changed, if there is a technically sound
alternative.


>  * Unorthodox in terms of XML architecture.

Not that XML is perfect, but yes, since SVG is based on XML,
that is a 
real challenge.

You seem to be in favor of the null-namespace option, but
the strongest 
reason you give seems to be the shared syntax.  Can you
supply a reason 
that the XHTML-namespace option won't work for both SVG and
(X)HTML5 
equally well?

Regards-
-Doug Schepers
W3C Staff Contact, SVG, CDF, and WebAPI

On Oct 10, 2007, at 21:13, Doug Schepers wrote:

> Henri Sivonen wrote (on 10/10/2007 11:21 AM):
>> I'm curious why a third way isn't mentioned:
>> 3) Non-Namespaced Attributes for both role and
states/properties  
>> with the latter prefixed with "aria-"
(and no qNames in content  
>> but opaque strings):
>> <svg
>>   xmlns="http://www.w3.org/20
00/svg"
>>   xmlnslink=
"http://www.w3.
org/1999/xlink">
>>   <g role="checkbox"
aria-checked="true">...</g>
>> </svg>
>
> That's an orthogonal issue to how role is
integrated into SVG.   
> It's worth talking about, but I think it can be
addressed as a  
> separate issue.  role in SVG will likely have more uses
than  
> accessibility.

I'm not sure using the same attribute as the ARIA hook and
as  
something unrelated is a good idea.

> Comments inline:
>
>> Pros:
>>  * Matches what has recently been proposed for
(X)HTML5 and XUL.  
>> Good both for implementation and author skill
portability.
>
> I agree that having a shared syntax is a worthwhile
goal, for the  
> reasons you mention.  Since there have been no
technical decisions  
> yet made for HTML5, it's hard to know what the status
of that  
> proposal is, especially since it is not quite in line
with the  
> XHTML Role Attribute Module spec.  Is there some
general consensus  
> on the proposal?

There seems to be browser implementor consensus to the
extent they  
have stated opinion.

>>  * Fewer namespaces to deal with (i.e. easier).
>
> Once the author has to deal with namespaces, it's not
entirely  
> clear that fewer namespaces is easier.  It is shorter,
for sure.

If SVG got a built-in href='' also, it would put namespaces 

completely out of sight except for the default incantation
on the  
root element.

>>  * DOM-friendly. (qNames in content are *bad* in
the DOM.)
>
> Can you elaborate on that?

DOM doesn't capture the namespace mapping scope at the node
creation  
time. It doesn't even provide API-native convenience methods
for  
resolving qNames-in-content into NS,localName pairs. Even if
you  
bother to walk the tree using code you wrote yourself
because DOM  
didn't do it for you, the meaning of qNames is brittle when
nodes are  
moved around. When you walk towards the root you may find
very  
different ns declarations if the node you start from has
been moved  
to another subtree after the initial DOM build.

QNames in content are a tolerable match for use cases where
a static  
XML file is parsed using a SAX parser (e.g. when compiling
an XSLT  
transformation). However, qNames in content are a really bad
match  
for dynamic DOM manipulation which is what ARIA is all
about.

>>  * Not a chameleon namespace per se. The attributes
would be in no  
>> namespace in XHTML5, SVG and XUL.
>
> I don't think that inherently avoids the issue I
raised, that there  
> may be potential interfaces implemented on the
attribute in one  
> language and not the others (which raises the same
problems as  
> chameleon namespaces, whether or not it's precisely the
same).  The  
> easiest resolution to that issue is an agreement that
the attribute  
> is defined in one mutually exclusive place, and that
all changes  
> are specified only in that single specification. 
(FWIW, I don't  
> see this as a pro or con, either way.)

I don't see why the DOM interfaces couldn't be defined in
one place  
either way. However, so far, ARIA seems to work on top of
DOM Core  
without specific interfaces.

>>  * Unorthodox in terms of XML architecture.
>
> Not that XML is perfect, but yes, since SVG is based on
XML, that  
> is a real challenge.

Politically, yes. Technically, not necessarily. 

> You seem to be in favor of the null-namespace option,
but the  
> strongest reason you give seems to be the shared
syntax.  Can you  
> supply a reason that the XHTML-namespace option won't
work for both  
> SVG and (X)HTML5 equally well?

It is desirable to be able to write (X)HTML5 processing
application  
internals once so that swapping the parser or serializer at
the IO  
boundary disrupts the app internals minimally. This means
going with  
the constraints of text/html which can only do no-namespace 

attributes. Even the handful of subtle differences we have
now  
between HTML5 and XHTML5 are a pain (e.g. lang vs.
xml:lang).

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

* Henri Sivonen wrote:
>DOM doesn't capture the namespace mapping scope at the
node creation  
>time. It doesn't even provide API-native convenience
methods for  
>resolving qNames-in-content into NS,localName pairs.
Even if you  
>bother to walk the tree using code you wrote yourself
because DOM  
>didn't do it for you, the meaning of qNames is brittle
when nodes are  
>moved around. When you walk towards the root you may
find very  
>different ns declarations if the node you start from has
been moved  
>to another subtree after the initial DOM build.

I have a hard time following your criticism. It is true that
the DOM is
unaware of possible dependencies between some content and
its context,
and moving nodes without reconstructing the context may have
undesirable
or unexpected effects. This is true for most inherited
declarations and
relative references (the language of the node may change due
to xml:lang
attributes, resource identifiers may change due to xml:base
attributes,
event handlers may behave differently because the node's
parent changed,
"QNames" may resolve to different names due to
xmlns attributes, etc.)

That's a rather general problem, and beyond that, I am not
sure what you
are saying. The DOM retains namespace declarations, you can
query and
update them and you can easily look up the namespace name
for a prefix
or the prefix for a namespace name; you might have missed
.lookupPrefix,
.isDefaultNamespace, and .lookupNamespaceURI, otherwise I
don't see why
you would walk the tree yourself.

Making yet more convenient methods would be difficult due to
differences
in "QName" semantics and limitations in the usual
programming languages;
for example, XML Schema maps unprefixed names to the
declared default
namespace, Atom link relations map them to http://www.iana.org/...
and
XSLT maps them to no namespace at all, and neither Java nor
ECMAScript
support tuples as return value unless you wrap them inside
something --
and then it'd be difficult to see how that's better than
using split().

Could you perhaps rephrase what problems you see here, other
than the
first I've mentioned above?
-- 
Bj�rn H�hrmann � mailto:bjoernhoehrmann.de � http://bjoern.hoehrmann.de

Weinh. Str. 22 � Telefon: +49(0)621/4309674 � http://www.bjoernsworld.de

68309 Mannheim � PGP Pub. KeyID: 0xA4357E78 � http://www.websitedev.de/ 

Hi, Henri-

Henri Sivonen wrote (on 10/10/2007 3:47 PM):
> 
> On Oct 10, 2007, at 21:13, Doug Schepers wrote:
> 
>> That's an orthogonal issue to how role is
integrated into SVG.  It's 
>> worth talking about, but I think it can be
addressed as a separate 
>> issue.  role in SVG will likely have more uses
than accessibility.
> 
> I'm not sure using the same attribute as the ARIA hook
and as something 
> unrelated is a good idea.

Why not?  It seems very pragmatic to me.


>> I agree that having a shared syntax is a worthwhile
goal, for the 
>> reasons you mention.  Since there have been no
technical decisions yet 
>> made for HTML5, it's hard to know what the status
of that proposal is, 
>> especially since it is not quite in line with the
XHTML Role Attribute 
>> Module spec.  Is there some general consensus on
the proposal?
> 
> There seems to be browser implementor consensus to the
extent they have 
> stated opinion.

And to what extent is that?  I suspect that most browser
implementors 
would be most happy to have some definitive specification or
proposal to 
implement interoperably, more than they would want any given
solution.

As far as I've seen, opinions differ among various employees
of each 
browser vendor, so I'd like to know that an opinion
expressed is the 
official and studied one of a vendor, not merely the opinion
of one 
employee.  The whole point of our asking for feedback is to
get the 
whole range of opinions, so we can reach the best conclusion
before we 
ask all the browser vendors to implement it.


>>>  * Fewer namespaces to deal with (i.e.
easier).
>>
>> Once the author has to deal with namespaces, it's
not entirely clear 
>> that fewer namespaces is easier.  It is shorter,
for sure.
> 
> If SVG got a built-in href='' also, it would put
namespaces completely 
> out of sight except for the default incantation on the
root element.

Well, that's worth considering, but again, out of scope for
the topic of 
how to adopt role in SVG.  It would require a
considerable (and 
incompatible) rewrite of SVG, and I'm not at all convinced
that that is 
really what is best for open standards in the face of market
pressure. 
Can you supply justification for this, beyond purity of
design?


>>>  * DOM-friendly. (qNames in content are *bad*
in the DOM.)
>>
>> Can you elaborate on that?
> 
> DOM doesn't capture the namespace mapping scope at the
node creation 
> time. It doesn't even provide API-native convenience
methods for 
> resolving qNames-in-content into NS,localName pairs.
Even if you bother 
> to walk the tree using code you wrote yourself because
DOM didn't do it 
> for you, the meaning of qNames is brittle when nodes
are moved around. 
> When you walk towards the root you may find very
different ns 
> declarations if the node you start from has been moved
to another 
> subtree after the initial DOM build.

The same could be said of namespaced content of any kind,
including SVG 
inline with XHTML.  If I move a <svg:circle> outside
of its root 
element, I will have exactly the same problem.  Do you see a
solution to 
this larger issue?


> QNames in content are a tolerable match for use cases
where a static XML 
> file is parsed using a SAX parser (e.g. when compiling
an XSLT 
> transformation). However, qNames in content are a
really bad match for 
> dynamic DOM manipulation which is what ARIA is all
about.

That's not my impression of ARIA.  Getting and setting
attribute values, 
yes, but not moving them around from element to element
randomly...


>> The 
>> easiest resolution to that issue is an agreement
that the attribute is 
>> defined in one mutually exclusive place, and that
all changes are 
>> specified only in that single specification.
> 
> I don't see why the DOM interfaces couldn't be defined
in one place 
> either way. 

It's not necessarily a technical issue, but one of
organization and ease 
of implementation.  For example, there are many SVG UAs that
don't 
implement HTML, and so having to reference HTML normatively
would mean 
that the UA implementor would have to find exactly those
parts of HTML 
that they need to implement.  As far as I can tell so far,
the current 
state of the HTML 5 spec seems pretty intertwingled, which
doesn't give 
me much confidence that any given bit could be safely
referenced by SVG. 
  It also makes updating and tracking changes to the
referenced spec 
needlessly complicated.

It's also a PITA in terms of W3C Process, but that's another
matter.


> However, so far, ARIA seems to work on top of DOM Core
> without specific interfaces.

So far.  But since it may have a complex value type, there
is reason to 
consider that might change in the future.


>>>  * Unorthodox in terms of XML architecture.
>>
>> Not that XML is perfect, but yes, since SVG is
based on XML, that is a 
>> real challenge.
> 
> Politically, yes. Technically, not necessarily. 

Both politically and technically.

Technically, SVG is able to rely on another spec to define
such things 
as parsing and other low-level details that are meant to be
shared among 
all related languages.  Without that basis, we would have to
define all 
these things in the SVG spec (again, more work I hope isn't
necessary), 
as is being done in HTML 5.  And again for every other
language.  It 
doesn't seem a cost-effective long-term solution, and is
only reasonable 
in HTML 5 because of legacy content.


>> You seem to be in favor of the null-namespace
option, but the 
>> strongest reason you give seems to be the shared
syntax.  Can you 
>> supply a reason that the XHTML-namespace option
won't work for both 
>> SVG and (X)HTML5 equally well?
> 
> It is desirable to be able to write (X)HTML5 processing
application 
> internals once so that swapping the parser or
serializer at the IO 
> boundary disrupts the app internals minimally. This
means going with the 
> constraints of text/html which can only do no-namespace
attributes. Even 
> the handful of subtle differences we have now between
HTML5 and XHTML5 
> are a pain (e.g. lang vs. xml:lang).

But given that they exist, how much more problem is it to
generalize the 
model?  And don't you have to deal with this already, given
that you may 
have to also parse inline SVG?


Regards-
-Doug Schepers
W3C Staff Contact, SVG, CDF, and WebAPI

On Oct 11, 2007, at 01:03, Doug Schepers wrote:

> Henri Sivonen wrote (on 10/10/2007 3:47 PM):
>> On Oct 10, 2007, at 21:13, Doug Schepers wrote:
>>> That's an orthogonal issue to how role is
integrated into SVG.   
>>> It's worth talking about, but I think it can be
addressed as a  
>>> separate issue.  role in SVG will likely
have more uses than  
>>> accessibility.
>> I'm not sure using the same attribute as the ARIA
hook and as  
>> something unrelated is a good idea.
>
> Why not?  It seems very pragmatic to me.

The idea of interleaving two completely unrelated lists of
tokens in  
one attribute seems intuitively brittle considering the
history of  
<object> that was supposed to be the element of all
trades.

Perhaps it can be arranged that consumers of different token
 
sequences can safely skip the tokens of the other
interleaved  
sequence without collisions and without too severe
performance  
problems. However, if making this skipping work requires
qNames in  
content to avoid collisions, I'd take two attributes over
qNames in  
one attribute any day.

>>> I agree that having a shared syntax is a
worthwhile goal, for the  
>>> reasons you mention.  Since there have been no
technical  
>>> decisions yet made for HTML5, it's hard to know
what the status  
>>> of that proposal is, especially since it is not
quite in line  
>>> with the XHTML Role Attribute Module spec.  Is
there some general  
>>> consensus on the proposal?
>> There seems to be browser implementor consensus to
the extent they  
>> have stated opinion.
>
> And to what extent is that?  I suspect that most
browser  
> implementors would be most happy to have some
definitive  
> specification or proposal to implement interoperably,
more than  
> they would want any given solution.

The Bugzilla action is at
h
ttps://bugzilla.mozilla.org/show_bug.cgi?id=396632

Simon Pieters from Opera is drafting spec text and I haven't
heard  
anything unfavorable from Opera.

As far as I've noticed, the other browser implementors have
been silent.

> As far as I've seen, opinions differ among various
employees of  
> each browser vendor, so I'd like to know that an
opinion expressed  
> is the official and studied one of a vendor, not merely
the opinion  
> of one employee.

It seems to me that vendor-level official pronouncements
about  
particular spec features are relatively rare compared to
casual  
opinions and actions of the people who work on a particular
feature.

>>>>  * Fewer namespaces to deal with (i.e.
easier).
>>>
>>> Once the author has to deal with namespaces,
it's not entirely  
>>> clear that fewer namespaces is easier.  It is
shorter, for sure.
>> If SVG got a built-in href='' also, it would put
namespaces  
>> completely out of sight except for the default
incantation on the  
>> root element.
>
> Well, that's worth considering, but again, out of scope
for the  
> topic of how to adopt role in SVG.  It would
require a  
> considerable (and incompatible) rewrite of SVG, and I'm
not at all  
> convinced that that is really what is best for open
standards in  
> the face of market pressure. Can you supply
justification for this,  
> beyond purity of design?

Ease of authoring arising for the purity of namespaceless
attributes.  
Also, it would simplify inline SVG in text/html.

However, due to backwards compatibility considerations,
getting rid  
of the xlink prefix might not be worth it. It doesn't mean
that it is  
a good idea to introduce more of the same, though.

>>>>  * DOM-friendly. (qNames in content are
*bad* in the DOM.)
>>>
>>> Can you elaborate on that?
>> DOM doesn't capture the namespace mapping scope at
the node  
>> creation time. It doesn't even provide API-native
convenience  
>> methods for resolving qNames-in-content into
NS,localName pairs.  
>> Even if you bother to walk the tree using code you
wrote yourself  
>> because DOM didn't do it for you, the meaning of
qNames is brittle  
>> when nodes are moved around. When you walk towards
the root you  
>> may find very different ns declarations if the node
you start from  
>> has been moved to another subtree after the initial
DOM build.
>
> The same could be said of namespaced content of any
kind, including  
> SVG inline with XHTML.  If I move a <svg:circle>
outside of its  
> root element, I will have exactly the same problem.  Do
you see a  
> solution to this larger issue?

That's not the same thing at all. The namespace,local pair
for  
element and attribute names is resolved and frozen at node
creation  
time and isn't affected if the node is moved around.

>> QNames in content are a tolerable match for use
cases where a  
>> static XML file is parsed using a SAX parser (e.g.
when compiling  
>> an XSLT transformation). However, qNames in content
are a really  
>> bad match for dynamic DOM manipulation which is
what ARIA is all  
>> about.
>
> That's not my impression of ARIA.  Getting and setting
attribute  
> values, yes, but not moving them around from element to
element  
> randomly...

No, the ARIA attributes themselves are not expected to get
moved  
around, but in an Ajax app, it is reasonable to expect
elements that  
host ARIA attributes to get cloned or moved around.

>>>>  * Unorthodox in terms of XML
architecture.
>>>
>>> Not that XML is perfect, but yes, since SVG is
based on XML, that  
>>> is a real challenge.
>> Politically, yes. Technically, not necessarily.

>
> Both politically and technically.
>
> Technically, SVG is able to rely on another spec to
define such  
> things as parsing and other low-level details that are
meant to be  
> shared among all related languages.  Without that
basis, we would  
> have to define all these things in the SVG spec (again,
more work I  
> hope isn't necessary), as is being done in HTML 5.  And
again for  
> every other language.  It doesn't seem a cost-effective
long-term  
> solution, and is only reasonable in HTML 5 because of
legacy content.

Well, since SVG in browsers shares the DOM implementation
with the  
HTML part of the engine, the HTML DOM legacy leaks to SVG as
well and  
it would be reasonable for SVG to inherit stuff from the
browser DOM  
legacy instead of inheriting stuff from the non-browser XML
space.

>>> You seem to be in favor of the null-namespace
option, but the  
>>> strongest reason you give seems to be the
shared syntax.  Can you  
>>> supply a reason that the XHTML-namespace option
won't work for  
>>> both SVG and (X)HTML5 equally well?
>> It is desirable to be able to write (X)HTML5
processing  
>> application internals once so that swapping the
parser or  
>> serializer at the IO boundary disrupts the app
internals  
>> minimally. This means going with the constraints of
text/html  
>> which can only do no-namespace attributes. Even the
handful of  
>> subtle differences we have now between HTML5 and
XHTML5 are a pain  
>> (e.g. lang vs. xml:lang).
>
> But given that they exist, how much more problem is it
to  
> generalize the model?

The problem is you cannot generalize them in a way that
doesn't either
  1) complicate non-browser apps that build on XML tools and
want to  
push text/html handling out of the core to the IO boundary
or
  2) break DOM scripting backwards compat in browsers.

> And don't you have to deal with this already, given
that you may  
> have to also parse inline SVG?

We don't do inline SVG in text/html yet. Personally, I hope
we'll get  
there. However, if we do, the main SVG complications will be
the  
xlink mapping, the /> syntax and SVG-native camelCaps. I
don't think  
it is a good idea to introduce more complications if we are
already  
entertaining inline SVG in text/html as a possibility.

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

On Oct 10, 2007, at 23:48, Bjoern Hoehrmann wrote:

> * Henri Sivonen wrote:
>> DOM doesn't capture the namespace mapping scope at
the node creation
>> time. It doesn't even provide API-native
convenience methods for
>> resolving qNames-in-content into NS,localName
pairs. Even if you
>> bother to walk the tree using code you wrote
yourself because DOM
>> didn't do it for you, the meaning of qNames is
brittle when nodes are
>> moved around. When you walk towards the root you
may find very
>> different ns declarations if the node you start
from has been moved
>> to another subtree after the initial DOM build.
>
> I have a hard time following your criticism. It is true
that the  
> DOM is
> unaware of possible dependencies between some content
and its context,
> and moving nodes without reconstructing the context may
have  
> undesirable
> or unexpected effects. This is true for most inherited
declarations  
> and
> relative references (the language of the node may
change due to  
> xml:lang
> attributes, resource identifiers may change due to
xml:base  
> attributes,
> event handlers may behave differently because the
node's parent  
> changed,
> "QNames" may resolve to different names due
to xmlns attributes, etc.)
>
> That's a rather general problem, and beyond that, I am
not sure  
> what you
> are saying.

It is a general problem for anything that is specified to
inherit  
along the tree and isn't captured in the node at the node
creation  
time. That xml:lang is brittle doesn't make qNames in
content less  
brittle.

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