Nabble - w3.org - public-cdf

WICD 1.0 Test Suite Issues

2009-12-11T14:16:04Z

Hello,

I am writing with regard to some issues I found with the WICD Mobile 1.0 Test Suite. As part of the process of creating an SVGT plugin to WebKit under Android (and using the Netscape plugin api) we decided here in the BitFlash group at Quickoffice to see what level of compliance we could achieve with the WICD 1.0 Test Suite. We discovered that we failed more tests than we expected. The reason appears to be the use of features beyond SVG Tiny 1.2. Our results were presented at the recent SVG Open 2009 in San Jose CA.

A number of svg files that make up the test suite use features that are not part of the SVG Tiny 1.2 specification. I met Daniel Herzog at the SVG Open and have since had some dialog with him. He kindly provided a recent, though likely not the latest, archive containing the svg files that comprise the WICD 1.0 test suite. Upon examining this content I produced a spreadsheet relating the discrepancies between the test suite svg files and the SVG Tiny 1.2 specification (see attached). It is our opinion that either the WICD 1.0 test suite is in error using this svg content or the WICD 1.0 specification needs some clarification on the relevance of SVG Tiny 1.2 and/or necessary extensions to meet the WICD 1.0 requirements.

Some of these discrepancies can be easily fixed while others might require more investigation. In particular, because SVGT has a uDOM, which is a subset of the full DOM, there are a number of DOM objects and methods that are not supported in SVGT. Could you please review the attached spreadsheet and provide a reply?

Regards,

Jim Ehrismann
Software Developer
office +1 613.895.2206
email jim.ehrismann@...

WICDsvg.xls (37K) Download Attachment

Re: WICD core "param render static" testcase bug

2009-05-07T13:53:53Z

Hey Erik,

thanks a lot, together with Timur and Lars we have fixed this now. We
also modified the samples a bit to make the difference between
declarative and scripted animation clearer and easier to describe.

Best regards,
Daniel

2009/5/6 Erik Dahlström <ed@...>:

> Hello cdf,
>
> I belive there's a bug in the testsuite, in the WICD Core 1.0 testcase #7 #9, "param render static" [1].
>
> According to 3.2.1.1 [2] scripted animations should still run if <param name="render" value="static"> is specified. The referenced svg image has both declarative and scripted animations (rotation is declarative, colorfade of arrow is scripted). The test pass criteria says:
> [[
> This test has passed, if the left SVG animates, while the animations of the right SVG are stoped.
> ]]
>
> It should say that the right SVG must not rotate, but that it must fade the color from black to white continously.
>
> Cheers
> /Erik
>
> [1] http://www.w3.org/2004/CDF/TestSuite/WICD_CDR_WP1/test-static-svg-child.xhtml
> [2] http://www.w3.org/TR/WICD/#supported-formats
>
> --
> Erik Dahlstrom, Core Technology Developer, Opera Software
> Co-Chair, W3C SVG Working Group
> Personal blog: http://my.opera.com/macdev_ed
>
>
>
>
>

WICD core "param render static" testcase bug

2009-05-06T00:11:32Z

Hello cdf,

I belive there's a bug in the testsuite, in the WICD Core 1.0 testcase #7 #9, "param render static" [1].

According to 3.2.1.1 [2] scripted animations should still run if <param name="render" value="static"> is specified. The referenced svg image has both declarative and scripted animations (rotation is declarative, colorfade of arrow is scripted). The test pass criteria says:
[[
This test has passed, if the left SVG animates, while the animations of the right SVG are stoped.
]]

It should say that the right SVG must not rotate, but that it must fade the color from black to white continously.

Cheers
/Erik

[1] http://www.w3.org/2004/CDF/TestSuite/WICD_CDR_WP1/test-static-svg-child.xhtml
[2] http://www.w3.org/TR/WICD/#supported-formats

--
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed

WICD Mobile 1.0 TestSuite: license question

2009-01-14T05:47:20Z

Dear Sir/Madam,

I am working on the JSR 290 Conformance Test Suite development.
Existing WICD Mobile 1.0 Test Suite provides very useful test cases
which could be reused to align both technologies to get best compliance
and less fragmentation among implementations.

Could you please answer my few questions about WICD Mobile Test Suite:
1. what license covers this test suite?
The specification is W3C License with Documentation rules and I wonder
if the test suite is indeed covered by Software version of the
license. In the
test suite I found no sign of the license at
http://www.w3.org/2004/CDF/TestSuite/WICD_CDR_WP1/wicdmobile.xhtml
2. can I reuse existing WICD Mobile 1.0 Test Suite test cases in JSR290
Conformance test suite development work?

Best regards,
Vasily

Too many ways to build compound documents

2008-12-28T05:04:01Z

I think that are too many different ways to build compound documents, either by reference or by inclusion.
At the moment we have:

1) XHTML2 embedding attributes
2) XHTML2 / 5 object
3) XHTML5 embed
4) XInclude
5) XLink type="embed" / type="resource"
6) CSS content: uri(); property
7) DTD external entities
8) XBL or XSLT (which could transform markup across languages)
9) Direct inclusion (ie plain writing or server-side processing)

Plus we have media specific, like svg image, xhtml 2/5 img, smil media object, css background-image / border-image;

I was wondering if any work was started to provide a unform way, instead of relying on single language capabilities (which seems the current orientation of CDRF and CDIF)

Giovanni

regrets

2008-09-11T00:58:53Z

regrets,

it is with profound regret that I find my other commitments prevent me from contributing further to developments at W3C.

I had always felt that w3c's reliance on commercial funding distorted the progress of specifications.

Most particularly in respect of the needs of the end-user and particularly the less literate, including the large community of people with learning disabilities.

Communication is most successful when it is a two-way process, this requires that specifications are rigorously tested to ensure that all users are enabled to author and publish on an equal footing, as far as is reasonable and possible.

Instead guilds are developing who's self interest has rather different motivations.

regards

Jonathan Chetwynd

j.chetwynd@...
http://www.openicon.org/

+44 (0) 20 7978 1764

Re: WICD Core 10.0: Intended Layout

2008-08-13T01:59:06Z

Hi Jose Manuel,

browser-adaptation and proxy-transformation are related, for sure. And
authors need to be able to switch off both adaptation techniques. I'm
just not convinced that there must be a single off-switch for the two
things.

If <meta name="viewport" .../> can be used to switch off browser-
adaptation and something else (maybe a HTTP header, maybe a handheld
style sheet) can be used to reliably prevent proxy-transformations,
wouldn't that be okay as well?

Browser vendors may lay out the argument for why media="handheld" does
not switch off browser adaptation. What I can say, is that meta/
viewport does seem to work just fine. And that w3 specs may need to
adjust - and not give wrong advice.

Timur

On 11.08.2008, at 16:58, JOSE MANUEL CANTERA FONSECA wrote:

> Hi Timur,
>
> The problem of not activating client-side, browser-made adaptation
> seems to be very similar to the problem of announcing that a web
> page is intended to mobile devices in order not to be "touched" by
> server-side Content Transformation Proxies. The CT Guidelines spec
> [1] advocates, among others, the usage of <link rel="alternate"
> media="handheld"> mechanisms to announce it.
>
> I think W3C needs to provide a unique solution to the problem and
> not to suggest different mechanisms in different specs.
>
> I'm ccing the BP group mailing list
>
> Best Regards
>
> [1] http://www.w3.org/TR/2008/WD-ct-guidelines-20080801/
>
>
> -----Mensaje original-----
> De: public-cdf-request@... [mailto:public-cdf-request@...] En
> nombre de Timur Mehrvarz
> Enviado el: miércoles, 06 de agosto de 2008 16:56
> Para: public-cdf@...
> Asunto: WICD Core 10.0: Intended Layout
>
>
> WICD Core 10.2 "Style sheet being provided for specific agent classes"
> says:
>
> A user agent that discovers a CSS style sheet, provided for its own
> device
> class, should assume the content was created with specific
> properties "in
> mind". The agent is then expected to deactivate any custom
> adaptation
> techniques (for example rendering wide screen content on a narrow
> screen)
> and display the intended layout "as is".
> http://www.w3.org/TR/WICD/#intended-layout-1
>
> When creating content for small screen devices, the ability to tell
> user agents to _not_ activate any adaptation techniques is
> indispensable.
>
> MobileSafari and Opera Mobile support this now - but differently. Both
> agents support the <meta name="viewport" content="..."> element in
> HTML as described here:
> http://developer.apple.com/documentation/AppleApplications/Reference/SafariWebContent/UsingtheViewport/chapter_4_section_5.html
>
> As a consequence, I request an update to WICD Core 10.2 and 10.3, so
> that the desired functionality does not anymore depend on the use of
> style sheets, but the meta/viewport element. The existing
> specification on developer.apple.com, refers to the iPhone only and it
> also does not specify the meta element for use in XHTML. It would be
> good to have a w3 rewrite of this functionality.
>
> Since two vendors support the desired behaviour already, two more
> fields in the WICD testsuite could go straight from red to green.
>
> Timur
>
>

RE: WICD Core 10.0: Intended Layout

2008-08-11T07:58:48Z

Hi Timur,

The problem of not activating client-side, browser-made adaptation seems to be very similar to the problem of announcing that a web page is intended to mobile devices in order not to be "touched" by server-side Content Transformation Proxies. The CT Guidelines spec [1] advocates, among others, the usage of <link rel="alternate" media="handheld"> mechanisms to announce it.

I think W3C needs to provide a unique solution to the problem and not to suggest different mechanisms in different specs.

I'm ccing the BP group mailing list

Best Regards

[1] http://www.w3.org/TR/2008/WD-ct-guidelines-20080801/

-----Mensaje original-----
De: public-cdf-request@... [mailto:public-cdf-request@...] En nombre de Timur Mehrvarz
Enviado el: miércoles, 06 de agosto de 2008 16:56
Para: public-cdf@...
Asunto: WICD Core 10.0: Intended Layout

WICD Core 10.2 "Style sheet being provided for specific agent classes"
says:

A user agent that discovers a CSS style sheet, provided for its own
device
class, should assume the content was created with specific
properties "in
mind". The agent is then expected to deactivate any custom adaptation
techniques (for example rendering wide screen content on a narrow
screen)
and display the intended layout "as is".
http://www.w3.org/TR/WICD/#intended-layout-1

When creating content for small screen devices, the ability to tell
user agents to _not_ activate any adaptation techniques is
indispensable.

MobileSafari and Opera Mobile support this now - but differently. Both
agents support the <meta name="viewport" content="..."> element in
HTML as described here:
http://developer.apple.com/documentation/AppleApplications/Reference/SafariWebContent/UsingtheViewport/chapter_4_section_5.html

As a consequence, I request an update to WICD Core 10.2 and 10.3, so
that the desired functionality does not anymore depend on the use of
style sheets, but the meta/viewport element. The existing
specification on developer.apple.com, refers to the iPhone only and it
also does not specify the meta element for use in XHTML. It would be
good to have a w3 rewrite of this functionality.

Since two vendors support the desired behaviour already, two more
fields in the WICD testsuite could go straight from red to green.

Timur

WICD Core 10.0: Intended Layout

2008-08-06T07:56:07Z

WICD Core 10.2 "Style sheet being provided for specific agent classes"
says:

A user agent that discovers a CSS style sheet, provided for its own
device
class, should assume the content was created with specific
properties "in
mind". The agent is then expected to deactivate any custom adaptation
techniques (for example rendering wide screen content on a narrow
screen)
and display the intended layout "as is".
http://www.w3.org/TR/WICD/#intended-layout-1

When creating content for small screen devices, the ability to tell
user agents to _not_ activate any adaptation techniques is
indispensable.

MobileSafari and Opera Mobile support this now - but differently. Both
agents support the <meta name="viewport" content="..."> element in
HTML as described here:
http://developer.apple.com/documentation/AppleApplications/Reference/SafariWebContent/UsingtheViewport/chapter_4_section_5.html

As a consequence, I request an update to WICD Core 10.2 and 10.3, so
that the desired functionality does not anymore depend on the use of
style sheets, but the meta/viewport element. The existing
specification on developer.apple.com, refers to the iPhone only and it
also does not specify the meta element for use in XHTML. It would be
good to have a w3 rewrite of this functionality.

Since two vendors support the desired behaviour already, two more
fields in the WICD testsuite could go straight from red to green.

Timur

Mission Audit

2008-07-27T02:42:59Z

Mission Audit

Ian,

attached an example of the type of feedback that could be invaluable when applied to W3C process.

regards

Jonathan Chetwynd

j.chetwynd@...
http://www.openicon.org/

+44 (0) 20 7978 1764

The Guardian Newspapers' recently published Sustainability Report: Living our values[1] contains such comments from Richard Evans, their auditor as:

"Would it be asking too much of the motoring editors to stop treating car ownership and use as a special case? It seems inconsistent to do so when a more holistic approach to sustainability is being adopted in news, science, economy and business coverage as well as other 'lifestyle' subjects. I would welcome some serious investigation on the part of GNM's motoring correspondents on readers' views on car ownership and use as well as alternative, more sustainable forms of transport."

[1] http://www.guardian.co.uk/sustainability

Re: WICD 1.0 implementation progress

2008-07-24T07:32:23Z

Hi, Timur-

Thanks! We were just looking at this again. :)

Regards-
-Doug

Timur Mehrvarz wrote (on 7/24/08 10:19 AM):

>
> We updated the WICD implementation matrix:
>
> - Added Opera Mobile 9.5.1 Beta1 (tested on a Windows Mobile handset
> device)
> - Filled in results for all "still missing" test cases. (The matrix is
> currently complete.)
>
> Timur
>
> http://www.w3.org/2004/CDF/TestSuite/WICD_CDR_WP1/
>

Re: WICD 1.0 implementation progress

2008-07-24T07:19:23Z

We updated the WICD implementation matrix:

- Added Opera Mobile 9.5.1 Beta1 (tested on a Windows Mobile handset
device)
- Filled in results for all "still missing" test cases. (The matrix is
currently complete.)

Timur

http://www.w3.org/2004/CDF/TestSuite/WICD_CDR_WP1/

communication between developers and 'Non-technical folk'

2008-07-23T02:03:57Z

Ian,

in support of the proposal regarding twenty percent of W3C time, can I draw your attention to this well reasoned blog on the need for communication between developers and 'Non-technical folk' by Chris Heilmann a well known accessibility advocate from Yahoo?

http://scriptingenabled.org/2008/07/the-biggest-barrier-to-accessibility-and-inclusive-design-is-us/

regards

Jonathan Chetwynd

j.chetwynd@...
http://www.openicon.org/

+44 (0) 20 7978 1764

On 18 Jul 2008, at 11:53, Jonathan Chetwynd wrote:

Ian,

I would like to propose that Working Group Charters** require participants including staff and members to devote at least twenty percent of their W3C time to enabling people with low literacy to participate in the web. This time should be shared equally between enabling exploring and authoring.

This requirement is in respect of the stated objectives of W3C to enable all people to communicate on the web and in recognition that approximately twenty percent of the population are illiterate.

regards

Jonathan Chetwynd
j.chetwynd@...
http://www.openicon.org/
+44 (0) 20 7978 1764

**Members of working groups are interpreting the current charters to prevent discussion of whether their charter is actually meeting the needs of end-users.
I have personal experience of this in respect of public lists and or phone conferences for WAI, SVG and CSS groups

David Woolley expresses a similar concern here:
http://lists.w3.org/Archives/Public/w3c-wai-ig/2008JulSep/0013.html

Re: 2nd Call: Full Potential: Who's counting?

2008-07-20T02:32:15Z

[ I'm not subscribed to public-cdf, so this will be delayed or may fail,
on that list. ]

Jonathan Chetwynd wrote:
> **Members of working groups are interpreting the current charters to
> prevent discussion of whether their charter is actually meeting the
> needs of end-users.
> I have personal experience of this in respect of public lists and or
> phone conferences for WAI, SVG and CSS groups
>

In my view, CSS, SVG, and HTML5 (html-public) groups are strongly
influenced by people who want the standards to benefit their businesses.
In theory the market ought to ensure that what is good for the public is
good for businesses, but in practice, most use of higher web
technologies in business is to actually distort the market (a whole
subject in itself).

Of the lists I monitor, I believe narrowing of the charter is most
obvious in CSS. From what has leaked into www-html, I think that it
probably also applies to html-public, although the biggest problem I see
with that is that it effectively created a coup in which industry moved
out of www-html, leaving those with higher principles behind, but
powerless. Both CSS and leakage from html-public has shown a dominance
by people who utterly reject accessibility because they see it as
irrelevant and bad for business.

In the case of CSS, I believe that one of the things that has happened
is that people have complained about the opacity of the process, so the
detail discussions have been moved into the public list, but people have
failed to understand is that problem with opacity is that it prevents
the general public from influencing the process. Instead, they have
basically removed that ability to influence by narrowing the charter to
just short term implementation issues, i.e. they have replaced the
public list with old private list, rather than combining them, and
basically left the operation of the committee unchanged.

To achieve this, they have relied on interpreting "technical" to mean
purely engineering issues (not that engineering should ignore the social
context), when I believe that the real intent of that word was to
discourage the use of the lists as authors' help desks (something that
I'm afraid Jonathon has been guilty of).

Basically, I think the mainstream web has been taken over by the same
people who used and created the tools that Tim explicitly rejected at
the time he first invented HTML. (You will actually find the suggestion
that the original web was for ivory tower users being used to defend the
current return to form over content.) Many of the people are probably
too young to realise that such tools existed before the web and think
they are creating new, when they are actually regressing.

I haven't noticed a denial of the original philosophy as so much of a
problem on w3c-wai-ig, but it is stil true that maybe 50% of that group
are in the accessibility industry, part of which is about telling
businesses how to meet accessibility legislation with minimum cost. As
such there is some tendency to use a narrow definition of accessibility,
that doesn't, for example include people who are disadvantaged purely
economically.

I think Jonathon has some problems with the WAI group because there are
big conflicts between designing for the illiterate and designing for
other disabilities, and also, authoring in a way that allows tools to
optimise for other disabilities requires good language skills on the
part of the author.

> David Woolley expresses a similar concern here:
> http://lists.w3.org/Archives/Public/w3c-wai-ig/2008JulSep/0013.html

My concern was that the process was being distorted to remove any
discussion of the social context of the web, or its history (which in my
view was based on a rejection of existing tools for central control of
information, in favour of empowering all humanity: by giving them access
to the knowledge needed for informed decisions (and thus to make a
market economy actually achieve what governments want it to achieve), by
giving them the ability to contribute their knowledge to the rest of the
world; and also giving them the power to choose how they viewed
information to best fit their individual needs, and to allow them to
avoid aspects of the presentations intended to distort their perception).

[ Original re-ordered ]
>
> I would like to propose that Working Group Charters** require
> participants including staff and members to devote at least twenty
> percent of their W3C time to enabling people with low literacy to

From things you have said elsewhere (and at the end of this article), I
think that the figure of 20% comes about because your definition of
having low literacy amounts to the lowest 20 percentile of the
population by literacy, and regardless of whether that figure comes
about by defining "functionally illiterate", by a percentile, or
measuring the percentile based on some other definition, equating it to
the time spent is unrealistic because:

- one can use the same argument for other disabilities, and might easily
end up accounting for more than 100% of the time, because people often
have multiple disabilities; In fact, even if one didn't double count, I
suspect you will find that almost everyone in the world has some disability;

- most people on committees are not there because of their expertise on
literacy and will find it difficult to work out what part of their time
is actually going on literacy issues. There is also the general time
sheet problem that people don't actually think solidly about one topic
for a set amount of time, but hop from subject to subject, or think of
solutions that address more than one area. Partitioning budgets can
even result in multiple locally optimal approaches, rather than a
better, globally optimal one.

There is also a significant danger that trying to account for time spent
on accessibility will make the funding companies aware of that time, and
therefore make them want to control or reduce that that time, as being
not profitable time.

- it's an unfortunate fact of life that W3C is funded by businesses,
both in cash and in terms of supplying expertise, and businesses will
only tolerate a limited spend on what they consider to be charitable
purposes that don't benefit them, financially, in the short term. If
they feel they are being required to spend significant resources that
are not of benefit, they will drop out of W3C and spend their web
standards budget elsewhere.

20% is actually an interesting figure as there is a business maxim
called the 20% rule, which basically says that you should ignore the
least profitable 20% of the market. That does mean that W3C has to
force consideration of minorities, because the management chain in the
employers of the committee members will be discouraging it, but I think
there are limits to what is achievable, given those managements are also
providing the funding.

I think it is very important that W3C maintains the moral high ground,
and am afraid that it has largely lost it in the last few years, but
efforts to do so either have to have overwhelming business cases, or
have to take into account how much their funders are prepared to
tolerate things which benefits humanity, but not their businesses.

- W3C is not a government, with the power to legislate, the the trend
amongst governments is to try and minimise regulation on businesses,
relying on the market (although, in my view, web standards are more and
more concentrating on providing tools for distracting consumers from the
facts they need to know for consumer markets to give the benefits of a
market, but that is a different subject, albeit also related to the
original goals of universal access to knowledge).

- Even if W3C does force committees to spend time, browser vendors and
authors will ignore the resulting advice if they do not see it as
profitable to them.

> participate in the web. This time should be shared equally between
> enabling exploring and authoring.
> >
>
I would suggest that the amount of effort that the W3C contributors will
tolerate on the total of all disabilities is likely to be less than 20%,
but that charters need to be framed to ensure that discussing the social
context of decisions, long term strategies, and the interpretation of
the charters is never off topic. Otherwise decisions will be made on
the basis of short term business advantages, which, for the web, I don't
believe align with long term benefit for humanity.

--
David Woolley
Emails are not formal business letters, whatever businesses may want.
RFC1855 says there should be an address here, but, in a world of spam,
that is no longer good advice, as archive address hiding may not work.

Re: 2nd Call: Full Potential: Who's counting?

2008-07-18T03:53:09Z

Ian,

I would like to propose that Working Group Charters** require participants including staff and members to devote at least twenty percent of their W3C time to enabling people with low literacy to participate in the web. This time should be shared equally between enabling exploring and authoring.

This requirement is in respect of the stated objectives of W3C to enable all people to communicate on the web and in recognition that approximately twenty percent of the population are illiterate.

regards

Jonathan Chetwynd

j.chetwynd@...
http://www.openicon.org/

+44 (0) 20 7978 1764

**Members of working groups are interpreting the current charters to prevent discussion of whether their charter is actually meeting the needs of end-users.

I have personal experience of this in respect of public lists and or phone conferences for WAI, SVG and CSS groups

David Woolley expresses a similar concern here:

http://lists.w3.org/Archives/Public/w3c-wai-ig/2008JulSep/0013.html

Re: WARNING-XML-CODEBASE-OBJECT-2nd Call: Full Potential: Who's counting?

2008-07-17T13:39:45Z

On Thu, 2008-07-17 at 21:22 +0100, Jonathan Chetwynd wrote:
> Ian
>
>
> What action has been taken in the past nine months to commission an
> external review?

None, to my knowledge.

_ Ian

>
> regards
>
>
> my logo
> Jonathan Chetwynd
>
> j.chetwynd@...
> http://www.openicon.org/
>
> +44 (0) 20 7978 1764
>
>
>
>
>
>
> Full Potential: Who's counting?
>
>
> Ian,
>
>
> Who is tasked with measuring and reporting on how or indeed whether
> W3C is fulfilling it's stated objective?
>
>
> Is this an external and independent body?
>
>
> Where are their reports published?
>
>
> regards
>
> Jonathan Chetwynd
> Accessibility Consultant on Media Literacy and the Internet
>
>
> http://www.w3.org/1998/02/Potential.html
> The first phase of the Web is human communication though shared
> knowledge.
>
>
> The Consortium exists as a place for those companies for whom the Web
> is essential to meet and agree on the common underpinnings that will
> allow everyone to go forward.
>
>
> http://www.w3.org/
> The World Wide Web Consortium (W3C) develops interoperable
> technologies (specifications, guidelines, software, and tools) to lead
> the Web to its full potential.
>
>
> http://www.w3.org/Consortium/org.html#public
> W3C Members include vendors of technology products and services,
> content providers, corporate users, research laboratories, standards
> bodies, and governments, all of whom work to reach consensus on a
> direction for the Web.
>
>
> http://www.w3.org/Consortium/Points/
> W3C's mission is to lead the Web to its full potential, which it does
> by developing technologies (specifications, guidelines, software, and
> tools) that will create a forum for information, commerce,
> inspiration, independent thought, and collective understanding.
>
>
> Today this universe benefits society by enabling new forms of human
> communication and opportunities to share knowledge. One of W3C's
> primary goals is to make these benefits available to all people,
> whatever their hardware, software, network infrastructure, native
> language, culture, geographical location, or physical or mental
> ability.
>
>

--
Ian Jacobs (ij@...) http://www.w3.org/People/Jacobs/
Tel: +1 718 260-9447

2nd Call: Full Potential: Who's counting?

2008-07-17T13:22:39Z

Ian

What action has been taken in the past nine months to commission an external review?

regards

Jonathan Chetwynd

j.chetwynd@...
http://www.openicon.org/

+44 (0) 20 7978 1764

Full Potential: Who's counting?

Ian,

Who is tasked with measuring and reporting on how or indeed whether W3C is fulfilling it's stated objective?

Is this an external and independent body?

Where are their reports published?

regards

Jonathan Chetwynd

Accessibility Consultant on Media Literacy and the Internet

http://www.w3.org/1998/02/Potential.html

The first phase of the Web is human communication though shared knowledge.

The Consortium exists as a place for those companies for whom the Web is essential to meet and agree on the common underpinnings that will allow everyone to go forward.

http://www.w3.org/

The World Wide Web Consortium (W3C) develops interoperable technologies (specifications, guidelines, software, and tools) to lead the Web to its full potential.

http://www.w3.org/Consortium/org.html#public

W3C Members include vendors of technology products and services, content providers, corporate users, research laboratories, standards bodies, and governments, all of whom work to reach consensus on a direction for the Web.

http://www.w3.org/Consortium/Points/

W3C's mission is to lead the Web to its full potential, which it does by developing technologies (specifications, guidelines, software, and tools) that will create a forum for information, commerce, inspiration, independent thought, and collective understanding.

Today this universe benefits society by enabling new forms of human communication and opportunities to share knowledge. One of W3C's primary goals is to make these benefits available to all people, whatever their hardware, software, network infrastructure, native language, culture, geographical location, or physical or mental ability.

Re: WICD 1.0 implementation progress

2008-07-01T08:25:32Z

WebKit nightly 34824 supports element traversal:
http://www.w3.org/2004/CDF/TestSuite/WICD_CDR_WP1/test-element-traversal.xhtml
http://bugs.webkit.org/show_bug.cgi?id=16489

Testsuite matrix updated:
http://www.w3.org/2004/CDF/TestSuite/WICD_CDR_WP1/wicdmatrix.xhtml

W3C/CDI WICD Profile

2008-06-29T14:18:57Z

In the "Compounding Semantics" department, here is a simple scheme to convolute [XHTML 1.0 with MathML 2.0] or [XHTML 1.0 with MODS 3.3], that is commentaries on Math or Bibliographic References (Meta Data).

The basic idea is that one could use Open Office to generate a XHTML wrapper, and use either OpenOffice Formula (MML) or Zotero (MODS) as a "foreign namespace" editor.

http://www.rustprivacy.org/FunForLibrarians.pdf (file names case sensitive)
http://www.rustprivacy.org/compound_docs.zip

Any comments are welcome.

--Gannon (J.) Dick

Re: WICD 1.0 implementation progress

2008-04-16T04:39:00Z

Re: WICD 1.0 implementation progress

2008-04-03T10:53:44Z

Opera 9.5 snapshot (build 4729) supports MQ "aspect-ratio" now (in
addition to "device-aspect-ratio"). Great!

WICD Implementation matrix updated:
http://www.w3.org/2004/CDF/TestSuite/WICD_CDR_WP1/wicdmatrix.xhtml#core-combined03

Timur

On 18.12.2007, at 01:33, Timur Mehrvarz wrote:
> I'm really happy to report this.
>
> Firefox 3.0b2-pre and Opera 9.5-alpha have fully implemented SVG
> Rightsizing. Yes!
> http://www.w3.org/2004/CDF/TestSuite/WICD_CDR_WP1/wicdmatrix.xhtml#core20

Re: MathML and SVG in text/html

2008-03-31T20:41:01Z

Hi, Folks-

Along these lines, several of us have just had a conversation on IRC,
where we discussed a possible extensibility point:
http://krijnhoetmer.nl/irc-logs/whatwg/20080401#l-441

We hashed out some ideas on the WHATWG wiki:
http://wiki.whatwg.org/wiki/Diagrams_in_HTML

The main open question is detailing how to handle tokenizer errors and
tree construction errors.

Note that this is not set in stone by any means, but is a positive
potential step forward.

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

Doug Schepers wrote (on 3/31/08 9:33 PM):

>
> Hi, CDF WG-
>
> The editor of the HTML5 specification is not convinced that MathML and
> SVG are the right choice for use in HTML. He apparently considers LaTeX
> and other formats as equally well suited as MathML [1], and VML and
> Windows Metafile format as equally well suited as SVG [2]. I don't know
> if he's genuine in this belief, or if he's merely setting expectations
> low so as to gain concessions to the markup and features allowed in
> text/html.
>
> I am inclined to believe that they are the most suitable formats
> (particularly SVG, though I find the arguments of the MathML advocates
> compelling, too); they have been designed from the ground up to be
> compatible with other Web technologies, specifially (X)HTML (and by
> extension HTML). However, he may be right that they do not fit within a
> vision for HTML which is a monolithic generalized language covering all
> domains of expression, as opposed to a framework of multiple
> interlocking languages where each performs a dedicated function with
> applicable semantics.
>
> This is the essence of CDF, of course, so as I mentioned at our last
> F2F, it may be that the best place for this to be specified is the the
> CDF WG, working closely with the HTML, XHTML, MathML, and SVG WGs. The
> CDF WG understands the importance of preserving the original formats of
> each language, and limits itself to defining the interactions between
> technologies. The HTML5 specification need only concern itself with the
> legacy requirements of the HTML language, and could provide a single
> point of extensibility, such as an <ext> element or a set of locations
> or circumstances under which other languages could be inserted.
>
> Naturally, the goal would still be to have the same DOM serialization in
> XHTML as in text/html. It would be a disservice to authors to introduce
> confusing incompatibilities. It's my belief that the markup itself
> should be a close as possible to the original formats as well, for the
> same reason.
>
> Given the momentum behind development in HTML in the browsers today, I
> think this may be the biggest bang for our buck, and I'd like to discuss
> this in our next telcon. What do you think?
>
> (Since we've agreed to act in public when the new charter goes through,
> I'm sending this to the public list, but also BCCing the CDF, MathML and
> SVG WG lists to make them aware. If you prefer to respond on the
> member-only list, I certainly respect your privacy.)
>
>
> [1] http://lists.w3.org/Archives/Public/public-html/2008Mar/0267.html
> [2] http://lists.w3.org/Archives/Public/public-html/2008Mar/0266.html
>
> Regards-
> -Doug Schepers
> W3C Team Contact, SVG, CDF, and WebAPI
>
>

Re: MathML and SVG in text/html

2008-03-31T19:21:03Z

Hi Doug,

Just looking at the New Vocabularies [1] on the WhatWG-Wiki it looks
like LaTeX is listed as a possibility. However on their Equations in
HTML [2] section of the wiki the LaTeX syntax is listed as "Rejected".
Both pages seem to be recently updated as well.

There is no mention of VML on New Vocabularies wiki page [1]. However,
when clicking on "Other ideas..." the pages linked had limited access.

I'm probably out spoken on this and perhaps I don't understand all the
issues, but I think that CDF should be specifying the way the different
standards interact in a web environment. The different standards group
((X)HTML, SVG, MathML) should concentrate on their respective
specifications as that is what they are best at.

Regards,

[1] http://wiki.whatwg.org/wiki/New_Vocabularies
[2] http://wiki.whatwg.org/wiki/Equations_in_HTML

Doug Schepers wrote:

--

Anthony Grasso

Software Engineer

Canon Information Systems Research Australia
1 Thomas Holt Drive, North Ryde, NSW 2113
AUSTRALIA

Phone: +61 2 8873 8821
Email: anthony.grasso@...

---

The information contained in this email message and any attachments may
be confidential and may also be subject to legal professional privilege.
If you are not the intended recipient, any use, interference with,
disclosure or copying of this material is unauthorised and prohibited.

If you have received this email in error, please immediately advise the
sender by return email and delete the information from your system.

MathML and SVG in text/html

2008-03-31T18:33:04Z

Hi, CDF WG-

The editor of the HTML5 specification is not convinced that MathML and
SVG are the right choice for use in HTML. He apparently considers LaTeX
and other formats as equally well suited as MathML [1], and VML and
Windows Metafile format as equally well suited as SVG [2]. I don't know
if he's genuine in this belief, or if he's merely setting expectations
low so as to gain concessions to the markup and features allowed in
text/html.

I am inclined to believe that they are the most suitable formats
(particularly SVG, though I find the arguments of the MathML advocates
compelling, too); they have been designed from the ground up to be
compatible with other Web technologies, specifially (X)HTML (and by
extension HTML). However, he may be right that they do not fit within a
vision for HTML which is a monolithic generalized language covering all
domains of expression, as opposed to a framework of multiple
interlocking languages where each performs a dedicated function with
applicable semantics.

This is the essence of CDF, of course, so as I mentioned at our last
F2F, it may be that the best place for this to be specified is the the
CDF WG, working closely with the HTML, XHTML, MathML, and SVG WGs. The
CDF WG understands the importance of preserving the original formats of
each language, and limits itself to defining the interactions between
technologies. The HTML5 specification need only concern itself with the
legacy requirements of the HTML language, and could provide a single
point of extensibility, such as an <ext> element or a set of locations
or circumstances under which other languages could be inserted.

Naturally, the goal would still be to have the same DOM serialization in
XHTML as in text/html. It would be a disservice to authors to introduce
confusing incompatibilities. It's my belief that the markup itself
should be a close as possible to the original formats as well, for the
same reason.

Given the momentum behind development in HTML in the browsers today, I
think this may be the biggest bang for our buck, and I'd like to discuss
this in our next telcon. What do you think?

(Since we've agreed to act in public when the new charter goes through,
I'm sending this to the public list, but also BCCing the CDF, MathML and
SVG WG lists to make them aware. If you prefer to respond on the
member-only list, I certainly respect your privacy.)

[1] http://lists.w3.org/Archives/Public/public-html/2008Mar/0267.html
[2] http://lists.w3.org/Archives/Public/public-html/2008Mar/0266.html

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

Re: SVG and MathML in text/html

2008-03-16T08:18:21Z

Hi, Maciej-

I'm taking this discussion to www-archive, since it affects a lot of
groups and a lot of interests. I'm BCCing related groups (HTML, SVG,
MathML, CDF, XHTML2), but discussions should take place on www-archive.
(This is part of a couple of long threads that started on blogs and
IRC, and were continued on public-html; I'd suggest that those
interested in this review those threads. [1][2])

To broaden the dialog to other audiences, so I'm going to try to
summarize the issue along the way. Please correct me if I fall astray,
or expand on points. I'm going to talk about SVG, but many of the same
issues may apply to MathML.

Maciej Stachowiak wrote (on 3/16/08 1:12 AM):
>
> HTML has the feature of two serializations: a classic serialization that
> is error-tolerant, and an XML-based serialization that has draconian
> error handling. These have different costs and benefits, ultimately it
> is a benefit to HTML authors that they have a choice. I think SVG
> deserves to have this feature as well, there's no reason it should fall
> short of HTML in this regard. Supporting SVG inline in text/html seems
> like a good opportunity to add this feature to SVG.

There are 2 scenarios here: SVG inline (Compound Documents by
Inclusion), and external SVG (Compound Documents by Reference). Your
proposal is that, in order to facilitate inline inclusion of SVG into
text/html, changes should be made to other uses of SVG, including those
intended for SVG-only UAs. I'll ask you to detail what changes would be
required, but the topic of hottest debate so far is the ability to use
unquoted attribute values in SVG, when there are no spaces or other
ambiguous characters. This would look something like this:

<circle id=circle_1 class="category1 medium" cx=75 cy=25 r=20
fill=orange stroke=red stroke-dasharray="3 5" />

You characterize this as non-draconian error handling; for the purpose
of authoring conformance, would this fragment indeed be in error (and
therefor in need of error recovery behavior), or would this be legal
syntax?

A counter-proposal is that SVG retain its existing serialization
(meaning, among other things, that it would require quoted attributes),
for inline (in both XHTML and text/html) and for external SVG documents
(standalone or externally referenced). I'm going to argue for this
proposal, as a Devil's Advocate, but I'm actually open to any proposals
that can be demonstrated as workable.

Given past author practice of copy-paste authoring, SVG that is written
inline in HTML is unlikely to stay there exclusively; it stands a very
good chance of being extracted and reused, be it referenced as an
external image, or as standalone content in a mobile SVG-only viewer, or
pasted into a graphical SVG authoring tool. Content that breaks from
one UA to another is too brittle, and would fracture the SVG market.
So, I agree with you here, that we shouldn't burden users, authors, and
vendors with multiple non-interoperable serializations.

As you mention, there are indeed known costs to any change in the
written form of SVG (the serialization), notably incompatibility with
all existing SVG viewers, authoring tools, automatic generators, and XML
processors up and down the entire toolchain in general. There is an
enormous infrastructure investment involved in an enterprise like this,
which affects not just SVG and MathML, but XML in general, and which
would require substantial costs in money, developer hours, and time to
market.

On mobile devices in specific, this would require implementors to write
a new parser (which has yet to be shown as practical on the Web in
general, or with SVG in specific); this may not be a burden for Apple
(or certain other desktop browser vendors), which has already invested
resources in an HTML UA, but it would certainly be for multiple other
mobile vendors (those not on the iPhone), who have a very large (in the
upper hundreds of millions) existing SVG UA deployment, and this could
have a substantial cost for them.

For desktop browsers, your proposed content would not work in the most
widely deployed SVG UA plugin for Internet Explorer (the Adobe viewer,
which though no longer maintained, is still the best and fastest overall
SVG UA for browsers); again, I can see this being a benefit for Apple,
but not necessarily for SVG. If Microsoft were to pledge and deliver
resources for adding high-quality native SVG support (at least as good
as Firefox, Opera, and WebKit), this would certainly alleviate my
concerns about desktop browsers.

With the XML serialization of SVG (the way it is now), authors are
already able to do inline SVG in the XML serialization of HTML (XHTML);
this works even in Internet Explorer using the Adobe viewer, by use of
"XML data islands"... and in fact works equally well in text/html and
XHTML (though it has to be served as text/html, a known problem in IE in
general).

Since it's not clear what changes would have to be made to SVG, your
proposal may or may not affect existing SVG content that is intended for
insertion into text/html; that is, presumably content can be made that
works in all SVG UAs, following the existing rules for SVG. So, this is
a neutral point... neither proposal would break existing content from
existing SVG authoring tools and generators. Still, it would be best to
get feedback from known tool vendors that produce SVG, such as Inkscape,
Illustrator, CorelDraw, GraphViz, Visio, and others (I'm probably
forgetting someone major, sorry).

As far as I know, there has been no implementation of the HTML5 parser
by a major browser vendor (though there have been test implementations
by others). The algorithm is relatively untested on the vast body of
existing HTML content on the Web, and completely untested for SVG
content. I'm concerned that this is taking an unnecessary risk with
SVG's future, in spite of its already growing appeal and popularity
across a variety of platforms, since it is competing with similar
proprietary technologies. I argue that this is a bad time to be taking
risks for what I see as a largely theoretical benefit to authors.

As I've stated before, in 8 years of active participation in the SVG
community, I've heard no serious request for unquoted attributes; by
contrast, I have heard many people extolling the benefits of the cleaner
XML model in contrast to the more complex HTML legacy. As it happens,
SVG makes liberal use of spaces in attributes, much more so than HTML,
so the analogies between the two are not quite accurate; the majority of
SVG content uses not the basic shapes like circles, lines, rectangles
and ellipses, but the more complex shapes represented by paths,
polygons, and polylines, and those elements use attribute values most
clearly represented by space-separated coordinate pairs. It's not clear
that there would be a substantive gain by authors in real-world content
by excluding attribute value quotes. Since SVG doesn't have the legacy
content of HTML content's unquoted attributes, there is little need to
extend the same rules to SVG as are necessary for HTML.

You state that "SVG deserves to have this feature as well" and that
"there's no reason it should fall short of HTML in this regard" as if
unquoted attributes are innately a clear benefit, rather than a burden
that implementors of HTML vendors and authors have to put up with,
because vendors have to deal with legacy content, and authors have to
maintain content they didn't create; SVG authors have never had to deal
with this before, and it's really not clear they want to. You represent
this as an authoring benefit, but I have not seen the evidence that this
is something authors are requesting. I may be wrong, but I'd like to be
proven wrong, rather than take it on faith.

In summary, as I see it, my proposal works today in a larger number and
wider variety of user agents, and imposes less burden on vendors, and
arguably on authors.

Could you summarize all the changes that you would require for SVG UAs
and authors to implement your proposal, and give the benefits and
rationales for each?

[1] http://lists.w3.org/Archives/Public/public-html/2008Mar/0039.html
[2] http://lists.w3.org/Archives/Public/public-html/2008Mar/0124.html

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

Article about CDF myths

2008-02-10T15:16:20Z

I have published a detailed article that responds to several myths about the work product of this working group. <http://www.universal-interop-council.org/?q=node/4>.

Best regards to all,

Paul Merrell ("Marbux")

FYI: WICD in WebKit

2008-01-21T16:24:59Z

fyi:

1) Core 1.0 #14: "WICD user agents must make all visible and focusable
points in the XHTML layer and the positioned Overlay Object reachable
and activatable."
http://bugs.webkit.org/show_bug.cgi?id=16483
"AFAICT the clicks should always hit the <object> element. Until this
is specified otherwise, I think this should be closed as invalid."

2) Mobile 1.0 #18-1: Support for SVG 1.2 editable="simple" attribute
on <text>
http://bugs.webkit.org/show_bug.cgi?id=16275
"Editing is mapped into style (-webkit-user-modify), so you can map
this SVG editable attribute into that and get editing behavior."

Re: Links to specs on CDF WG home page not displaying in Firefox

2008-01-14T11:47:05Z

Yup. They're visible now.

Thanks,

Marbux

On Jan 14, 2008 11:46 AM, Doug Schepers <schepers@...> wrote:

Hi-

Thanks for the report. It works in my version of Firefox, but the color
contrast for visited links against the background is rather low.

I've changed the visited-links color in the stylesheet. I hope that helps.

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

marbux wrote (on 1/14/08 5:30 AM):
> The links to the various WG candidate recommendations on the CDF WG public
> home page do not display on my instance of Firefox 2.0.0.11 unless I mouse
> over them. No such problem using MSIE 7. This started a few weeks back with
> only two of the links invisible without a mouse-over. A few days ago, all
> four began behaving similarly.
>

Re: Links to specs on CDF WG home page not displaying in Firefox

2008-01-14T11:46:14Z

Hi-

Thanks for the report. It works in my version of Firefox, but the color
contrast for visited links against the background is rather low.

I've changed the visited-links color in the stylesheet. I hope that helps.

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

marbux wrote (on 1/14/08 5:30 AM):
> The links to the various WG candidate recommendations on the CDF WG public
> home page do not display on my instance of Firefox 2.0.0.11 unless I mouse
> over them. No such problem using MSIE 7. This started a few weeks back with
> only two of the links invisible without a mouse-over. A few days ago, all
> four began behaving similarly.
>

Links to specs on CDF WG home page not displaying in Firefox

2008-01-14T02:30:37Z

The links to the various WG candidate recommendations on the CDF WG public home page do not display on my instance of Firefox 2.0.0.11 unless I mouse over them. No such problem using MSIE 7. This started a few weeks back with only two of the links invisible without a mouse-over. A few days ago, all four began behaving similarly.

Re: xml:id

2008-01-09T07:03:25Z

On Jan 9, 2008, at 16:05, Daniel Veillard wrote:

> On Wed, Jan 09, 2008 at 12:07:14PM +0200, Henri Sivonen wrote:
>> On Jan 9, 2008, at 07:01, Daniel Veillard wrote:
>>> Do SVG implementation actually parse/handle the DTD embedded in Web
>>> documents ?
>>
>> They don't generally.
> [...]
>>> I doubt it, in that case you rely on hardcoded behaviour of the
>>> engine,
>>
>> You don't need to rely on SVG engine-level hardcoding if you move the
>> hardcoding layer (at least conceptually) to between the XML processor
>> and the DOM builder. After all, that's were you'd put an xml:id
>> Processor.
> [...]
>>> What you are suggesting may be better from a code behaviour
>>> viewpoint *now* but from an user data point of view,
>>> generic processing, long term management of those, it sounds safer
>>> to use an ID handled at the XML level,
>>
>> xml:id isn't on the XML level. It is immediately on one level above
>> the XML level.
>
> Hum, strange that's not the case in my implementation, xml:id
> is handled as if an internal subset had defined it as being of type ID
> in the XML document, it's XML level, really. The best proof is that
> it uses an 'xml' hardcoded prefix, it's below namespaces in practice.

Norman Walsh's implementation is a SAX filter outside the XML
processor. (My IDness assignment implementation is a SAX filter as
well.) The formulation of xml:id processing using the notion of an
xml:id Processor as a "software module that works in conjunction with
an XML processor" supports the view that xml:id doesn't redefine the
XML layer but adds a processing layer on top of it. Even if this
processing layer is above the namespace layer, the namespace spec
makes the "xml" prefix mapping hard-wired, so to order of xml:id and
namespace processing don't make a practical difference.

>> I'm suggesting assigning IDness to id in no namespace
>
> You are suggesting only specific tools can process the data
> customers will
> put on the web ?

I'm suggesting that any application that wants to perform ID-sensitive
operations on XHTML, SVG or MathML (or in the future XBL2) documents
retrieved from the Web without a bilateral agreement with the document
author about xml:id use has to and will have to treat the id attribute
in no namespace as an attribute that participates in those operations.

> [...]
>>> There is certainly Web engine which don't recognize xml:id now, but
>>> if the web content is targetting reuse and long lifetime I would
>>> avoid relying just on the SVG hardcoded behaviour.
>>
>> Considering long life time, browsers can never stop supporting the
>> IDness of id in no namespace on XHTML, MathML and SVG elements.
>
> Must be a yes to the previous question ... Well it is also sometimes
> useful to extract data with generic tools, to automate processing.

Generic tools could add a processing layer for assigning IDness to id
in no namespace. (Implementations that don't report duplicate IDs and/
or that don't support CML can probably even ignore the CML
grandfathering issue.)

> I guess it all comes back from the original XML example of including
> data
> in Web pages and still be able to extract them as non-rendered content
> useful for a wide variety of applications, not necessarilly a
> dedicated
> fat engine with hardcoded knowledge of a set of vocabularies.

If an implementation doesn't report duplicate IDs, it can probably get
away with not knowing about particular vocabularies and
unconditionally assigning IDness to id in no namespace.

> If it's the 'xml:' prefix which really itches you, I somehow
> understand your fear of namesapce, but really this is just syntactic
> sugar in that case and that reaction should really not lead to a
> specialization of tools to process the customer data, it's really
> not worth it !

What itches me is introducing the 'xml:' prefix so late that it cannot
be used exclusively due to backwards compatibility issues. When it
cannot be used exclusively, it doesn't solve a problem but only makes
it more complex.

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

Re: xml:id

2008-01-09T06:04:35Z

On Wed, Jan 09, 2008 at 12:07:14PM +0200, Henri Sivonen wrote:
> On Jan 9, 2008, at 07:01, Daniel Veillard wrote:
> >Do SVG implementation actually parse/handle the DTD embedded in Web
> >documents ?
>
> They don't generally.
[...]
> >I doubt it, in that case you rely on hardcoded behaviour of the
> >engine,
>
> You don't need to rely on SVG engine-level hardcoding if you move the
> hardcoding layer (at least conceptually) to between the XML processor
> and the DOM builder. After all, that's were you'd put an xml:id
> Processor.
[...]
> >What you are suggesting may be better from a code behaviour
> >viewpoint *now* but from an user data point of view,
> >generic processing, long term management of those, it sounds safer
> >to use an ID handled at the XML level,
>
> xml:id isn't on the XML level. It is immediately on one level above
> the XML level.

Hum, strange that's not the case in my implementation, xml:id
is handled as if an internal subset had defined it as being of type ID
in the XML document, it's XML level, really. The best proof is that
it uses an 'xml' hardcoded prefix, it's below namespaces in practice.

>I'm suggesting assigning IDness to id in no namespace

You are suggesting only specific tools can process the data customers will
put on the web ?

[...]
> >There is certainly Web engine which don't recognize xml:id now, but
> >if the web content is targetting reuse and long lifetime I would
> >avoid relying just on the SVG hardcoded behaviour.
>
> Considering long life time, browsers can never stop supporting the
> IDness of id in no namespace on XHTML, MathML and SVG elements.

Must be a yes to the previous question ... Well it is also sometimes
useful to extract data with generic tools, to automate processing.
I guess it all comes back from the original XML example of including data
in Web pages and still be able to extract them as non-rendered content
useful for a wide variety of applications, not necessarilly a dedicated
fat engine with hardcoded knowledge of a set of vocabularies. If it's
the 'xml:' prefix which really itches you, I somehow understand your
fear of namesapce, but really this is just syntactic sugar in that case
and that reaction should really not lead to a specialization of tools
to process the customer data, it's really not worth it !

I certainly don't want to reopen a flamefest. Maybe xml:id
doesn't suit your needs, I just hope it will be reviewed
with an honnest perspective.

Daniel

--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel@... | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/

Re: xml:id

2008-01-09T02:07:14Z

On Jan 9, 2008, at 07:01, Daniel Veillard wrote:
> On Tue, Jan 08, 2008 at 03:25:32AM -0800, Maciej Stachowiak wrote:
>> On Jan 7, 2008, at 4:18 PM, Timur Mehrvarz wrote:
>>
>>> Are you really suggesting for authors to duplicate id and xml:id, in
>>> order to cope with this?
>>
>> I can't speak for Henri, but I would suggest authors use only id in
>> SVG content, and not xml:id, since id is more compatible and xml:id
>> offers no advantages for publicly deployed web content.

I'm not sure who "you" in the question referred to, but I agree with
Maciej.

> Do SVG implementation actually parse/handle the DTD embedded in Web
> documents ?

They don't generally.

> I doubt it, in that case you rely on hardcoded behaviour of the
> engine,

You don't need to rely on SVG engine-level hardcoding if you move the
hardcoding layer (at least conceptually) to between the XML processor
and the DOM builder. After all, that's were you'd put an xml:id
Processor.

> and in my opinion it's better to rely on a low level hardcoded
> behaviour (basically xml:id is an hardcoded DTD bypass)
> than one coming from upper layers which are less generic and
> sometimes can be conflicting.

I'm suggesting putting the IDness assignment exactly on the level of
lowness you'd put the xml:id Processor.

> What you are suggesting may be better from a code behaviour
> viewpoint *now* but from an user data point of view,
> generic processing, long term management of those, it sounds safer
> to use an ID handled at the XML level,

xml:id isn't on the XML level. It is immediately on one level above
the XML level. I'm suggesting assigning IDness to id in no namespace
(possibly making a grandfathered exception for CML elements) on the
level where the xml:id spec specifies assigning IDness to id in the http://www.w3.org/XML/1998/namespace
. What I'm suggesting is exactly as low or high level as xml:id.

> and since DTD processing is not guaranteed xml:id should be the most
> reliable option.

That's a false dichotomy.

> There is certainly Web engine which don't recognize xml:id now, but
> if the web content is targetting reuse and long lifetime I would
> avoid relying just on the SVG hardcoded behaviour.

Considering long life time, browsers can never stop supporting the
IDness of id in no namespace on XHTML, MathML and SVG elements.

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

Re: xml:id

2008-01-09T01:57:10Z

On Wed, 09 Jan 2008 06:01:18 +0100, Daniel Veillard <daniel@...>
wrote:
> There is certainly Web engine which don't recognize xml:id now,
> but if the web content is targetting reuse and long lifetime
> I would avoid relying just on the SVG hardcoded behaviour.

I fail to see how this matters for SVG, (X)HTML, MathML, or XBL content
for that matter as these markup languages all include an id="" attribute
that behaves in the same way. User agents processing those languages need
to be aware of way more than the IDness of the id="" attribute.

Now for Web browsers it would have made things better if the id=""
attribute were made a global attribute in XML as opposed to xml:id
(considering the primary authoring language uses that and all), but it
seems unlikely that this error will be fixed with xml:id in place.

--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Re: xml:id

2008-01-08T21:01:18Z

On Tue, Jan 08, 2008 at 03:25:32AM -0800, Maciej Stachowiak wrote:

>
>
> On Jan 7, 2008, at 4:18 PM, Timur Mehrvarz wrote:
>
> >Hello, we have a bit of controversy around xml:id. A link to a
> >previous post of mine:
> >http://lists.w3.org/Archives/Public/public-cdf/2008Jan/0000.html
> >
> >Apparently related to this:
> >http://lists.w3.org/Archives/Public/www-svg/2007Oct/0113.html
> >
> >Situation is, that some of our test cases fail, if xml:id is not
> >supported for SVG content:
> >http://www.w3.org/2004/CDF/TestSuite/WICD_CDR_WP1/wicdmatrix.xhtml#mobile10-2
> >
> >Are you really suggesting for authors to duplicate id and xml:id, in
> >order to cope with this?
>
> I can't speak for Henri, but I would suggest authors use only id in
> SVG content, and not xml:id, since id is more compatible and xml:id
> offers no advantages for publicly deployed web content.

Hi Maciej,

Do SVG implementation actually parse/handle the DTD embedded in Web
documents ? I doubt it, in that case you rely on hardcoded behaviour
of the engine, and in my opinion it's better to rely on a low level
hardcoded behaviour (basically xml:id is an hardcoded DTD bypass)
than one coming from upper layers which are less generic and sometimes
can be conflicting. What you are suggesting may be better from a code
behaviour viewpoint *now* but from an user data point of view,
generic processing, long term management of those, it sounds safer
to use an ID handled at the XML level, and since DTD processing is
not guaranteed xml:id should be the most reliable option.
There is certainly Web engine which don't recognize xml:id now,
but if the web content is targetting reuse and long lifetime
I would avoid relying just on the SVG hardcoded behaviour.

Daniel

--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel@... | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/