Various Topics (was: sockets)

Hi, Jonathan-

Jonathan Chetwynd wrote (on 9/7/08 4:14 AM):
> 
> I am concerned by comments such as
> 
> "I'm confident that any problems that are being discussed now will be
> resolved to the satisfaction of the browser implementors. "
> 
> which show little appreciation of the needs of end users, as discussed
> at length by me elsewhere. for instance as a requirement to include them
> and their representatives in the spec process.

Which is why I followed that sentence with this one:
[[
 Standards are most useful for establishing interoperability
 and providing authors and users with clear and precise
 guidelines to functionality that they can use.
]]

You omitted the part which specifically addresses the role of standards
for end-users and authors, which is disingenuous.

This list is not a forum for rants, trolling, political posturing, or
accusations; it is a forum for informed discussion.  I remind you to
please act fairly in your responses, as required by the Process
Document's participation criteria [1].  This is not a debate club, it is
a group of people selected for their ability to collaborate productively
to meet specific goals.  Please don't act in a disruptive way.


> I am concerned that my efforts to encourage creation of a reduced spec
> or microformat is not being encouraged, in fact being either ignored or
> discouraged.

Correct, the SVG WG has no intention of creating a reduced spec beyond
those already defined in the mobile/tiny/basic profiles.  Nor is there a
clear need to do so.  You could independently produce some authoring
guidelines that demonstrate why authors may wish to use only a subset of
the full capabilities of SVG, and to publish them on your own site.
Personally, I don't see any such need.  Instead, I encourage this group
to help ensure that there is a core set of interoperable SVG features
and functionality available in all browsers, and to produce documents
that inform authors on what features they may confidently use in their
content.  If this is successful, your hypothetical subset of SVG should
work by default.

As far as a microformat for SVG, you need to clarify your aims and the
desired outcome.  If what you want is a way to "tag" elements with
metadata about the function of that element, some combination of
<title>, <desc>, and 'xlink:title' are already available to provide
human-readable metadata, and ARIA provides an ontology to
machine-identify GUI elements such as buttons, drop-downs, and other
such widgets (to be used with the 'role' attribute) for use with AT and
general purposes.

For other types of microformats, SVG already has most of the hooks that
would be needed for authors to use or develop their own
SVG/graphic-specific microformats (@id, @class, @xlink:href); in SVG 1.2
Tiny, we've seen the need to allow authors to use microformats and RDFa
(I'd like to, myself), and have therefore placed some additional
attribute hooks to make it as simple as in X/HTML (stay tuned to the
next draft). [2]

I know you've worked in the past on an RDF Schema for a GUI vocabulary
[3], so maybe you can rework and leverage that to build momentum in the
RDFa community, if ARIA doesn't meet your needs (though I'm skeptical
about that).

The Microformats community is very much DYI.  It started as an informal
grassroots effort, and it seems to function well that way.  Coming to
the Microformats community, or this SVG IG, with some solid groundwork
in what you're trying to achieve is the best way to get it going.  Don't
rely on the SVG WG to do it, because we have other fish to fry.  If it's
important to you, you should be the one to commit time and resources to
working on it.  We have put the tools in place for you to do so.


> communication is a two way process.
> This means there is a need for simple and easy to use authoring tools
> but also real-time communication and
> people with learning disabilities will benefit from multi-user games, as
> they also promote communication.
> xmlhttprequest is not the default method currently used for these games
> and it would be helpful to include sockets whether tcp, websocket or
> other at the earliest opportunity.

XHR (XMLHttpRequest) is broadly supported across browsers, is
well-documented and widely used, and does enable real-time
collaboration, communication, and multi-user systems.  There are plenty
of examples of its use for this on the Web, and numerous tutorials on
how to set up such functionality.  By contrast, sockets are largely
experimental and not widely deployed in standards-based browsers (unlike
in mobile devices).

The clear choice at this time is to use XHR for desktop browser content,
unless there's a clear technical limitation that you haven't mentioned
that would make it unsuitable.


> as you will know I am reducing my email contributions, delayed responses
> can be expected.

I don't mind delayed responses; we are all busy.  However, I encourage
you not to merely make hit-and-run suggestions with no follow-through,
but to submit well-formulated proposals instead, or we will probably not
be able to give your ideas the priority you would like.


[1]
http://www.w3.org/2005/10/Process-20051014/policies.html#ParticipationCriteria
[2] http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/0251.html
[3] http://www.peepo.co.uk/temp/gui-schema

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

Received on Thursday, 11 September 2008 05:08:51 UTC