[ink] Responses to Al Gilman (former Protocol and Formats WG chair)'s InkML working draft comments

Hello Janina,

The former chair of the WAI Protocols and Formats Working Group, Al Gilman, made a set of comments against the InkML Working Draft on 2006-12-18 (http://lists.w3.org/Archives/Public/www-multimodal/2006Dec/).  The InkML working group now has a response to each of these comments, but since Al is no longer the chair, we are sending the responses to you as the current chair of the Protocols and Formats Working Group.

All comments and our responses have been recorded in the InkML 1.0: Working Draft Disposition of Comments document (http://www.w3.org/2002/mmi/2010/InkML/ED-InkML-20100811/inkml-disp.xml  ).   A copy of Al's comments and our responses are also copied below.

The latest draft of the InkML specification can be found here: http://www.w3.org/2002/mmi/2010/InkML/ED-InkML-20100811/ .

Thank you!

The InkML Editors:
        Tom Underhill, Microsoft
        Stephen M. Watt, University of Western Ontario

============
Comment #2:
------------
Orphan 'The'

In: http://www.w3.org/TR/2006/WD-InkML-20061023/#OverviewElements

there is an orphan sentence fragment 'The' at the end of the paragraph before the example.
------------
Resolution: accepted
------------
Removed the orphaned 'The'.
============
Comment #14:
------------
A bare anyURI is inadequate as inkml:ink.documentID

Reference:
http://www.w3.org/TR/2006/WD-InkML-20061023/#inkElement

You have given no interoperable definition of what kinds of assertions constitute "application intent" and content formats should define what semantics they denote independent of the processors.

So the bounds on when two files can bear the same URI as this
attribute are undefined.

Just don't let yourselves get caught in the rathole around URIs as to
what sort of repeatability constitutes an identity to which such a
symbol can be attached.

Instead, use Dublin Core to identify the contents if there is the
intent for the contents to be a published entity for which it makes
sense to compare identity codes.

In other words, you may use dc:identifier for this symbol but you
should only do that in the context of a dc:creator and a dc:date, for
example.

Comment: Needs to understand the complexity in naming the document that cited by the commenter.
ACTION ITEM: To check other WG for any best practices followed for this.
------------
Resolution: rejected
------------
If application requires particular attribution using Dublin Core, they may put DC XML in an AnnotationXML block.
============
Comment #18:
------------
traceFormat has? associated inkSource

Reference:
http://www.w3.org/TR/2006/WD-InkML-20061023


<quote
cite="http://www.w3.org/TR/2006/WD-InkML-20061023/#time">

The time channel can be specified as either a regular or intermittent
channel. When specified as a regular channel, the single quote prefix can be used to record incremental time between successive points.
Otherwise, the value of the time channel for a given sample point is
defined to be the timestamp of that point in the units and frame of
reference specified by its corresponding <inkSource> description
(more precisely, by the <traceFormat> element for the channel).

As with the other predefined channels, the meaning of the integer or
decimal values recorded by the time channel in a given trace is
defined by the <inkSource> information associated with the trace's
traceFormat. In the case of the time channel, its <channel> element
contains both a units and respectTo attribute.

</quote>

There is no provision through a sub-element or attribute to cite an
associated inkSource from the traceFormat element. These references to "its corresponding <inkSource> description" or "the <inkSource> information associated with the trace's traceFormat" appear to refer to an association that the format fails to construct.

What gives?
------------
Resolution: accepted
------------
Rephrasing the documentation
>From : '....Otherwise, the value of the time channel for a given sample point is defined to be the timestamp of that point in the units and frame of reference specified by its corresponding <inkSource> description (more precisely, by the <traceFormat> element for the channel)'
To: 'The Value of the time channel for a given sample point is defined to be the timestamp of that point in the units and frame of reference specified by the 'respectTo' attribute of the Time Channel that is defined in the associated TraceFormat of the trace.'
============
Comment #20:
------------
Be more explicit about binding reported data to intermittent channels

<quote
cite=http://www.w3.org/TR/2006/WD-InkML-20061023/#trace>

For each point in the trace, regular channel values are reported
first in the order given by the <traceFormat>. If any intermittent
values are reported for the point, they are given next, in the order
they are specified in the <traceFormat>. Unreported intermittent
channels are interpreted as though they were given by the wildcard
"*".
</quote>

This is not an algorithm. There is only one way to interpret it as an
algorithm, but that takes a friendly reading.

The problem is that if some intermittent channels produce no data at a given trace time, they can be omitted from of the reported data
without benefit of placeholders or wild cards and the resulting
reported data will still be *in the order given by <traceFormat>*. So
the specification language is too loose to enforce the behavior
that you seek.

You should ensure by the specification language that any channels
declared in the traceFormat before channels contributing non-* values are reported, even if only with wild cards. The language you have given does not ensure that.

Say something like:

The sequence of reported channels is a head for the sequence of
declared channels, the sequence given in the applicable <traceFormat>.

All Channels declared after the last reported channel are treated
as though a '*' were reported. All channels declared before the
last reported channel must also be reported, if only with explicit wild cards.
------------
Resolution: accepted
------------
* Changed the Grammar in section 3.2.1 to include value for 1) regular channel and 2) intermittent channel.
* The 'quoted' documentation has been be revised to the suggestion given by the commenter.
============
Comment #21:
------------
Disallow all qualifiers in intermittent channels

<quote
cite="http://www.w3.org/TR/2006/WD-InkML-20061023/#trace">

Intermittent channels are always encoded explicitly, i.e. the
qualifiers ' and " are not allowed.

</quote>

... and there's no point in using the qualifier, either, as it is implied.

So just don't allow qualifiers in intermittent channels, period. Saves one representation ambiguity for the interpreting application to have to code for.

PS: editorial: use angle brackets to set off quotes where you would have used quotes to make it clear that you are referencing the character as a token. In other words,

Intermittent channels are always encoded explicitly, i.e. the
qualifiers < '> and <"> are not allowed.

... but you're not going to need to call them out individually, here, once you fix it.
------------
Resolution: accepted
------------
This issue is related to the previous issue. Only the grammar for the 'regular' channel will have the qualifiers.
============
Comment #28:
------------
Pen rotation axis has undefined origin

Reference:
http://www.w3.org/TR/2006/WD-InkML-20061023

Your solid geometry was doing fine in defining the pen attitude coordinates
until you came to pen rotation.

<quote
cite="">
Figure 3b shows the Rotation of the pen along its longitudinal axis.
</quote>

There needs to be a definition of what the orientation of the pen is
when this coordinate is zero; the origin of the angular measure that
gets reported.

One possible definition is as follows:

The departure of a reference mark or meridian on the pen barrel from the nominal 'up' direction which may be constructed by a ray
perpendicular to the pen barrel (somewhere not at the tip) and
intersecting a pure-Z ray arising from the tip. This angle is
measured in a clockwise direction when viewing the pen barrel from
tail to tip, in degrees.

This definition would relate well to the force distribution across
the two sides of a fountain pen nib.

A different way to identify the nominal 'up' direction would be the
plane passing through the pen barrel and a pure-Y ray passing through the tip. Here the 'up' direction is a direction that has negative correlation with the Y axis, which normally flows down.

This definition would relate well to the use of an x-acto art knife,
indicating the user's intent as to whether the next bit of the trace
should be increasing or decreasing in X coordinate.

Each of these example definitions is just a quick blurt; you can say
it more simply but you have to say something more than you have said.
------------
Resolution: accepted
------------
Changed the definition for the rotation of pen to "The departure of a reference mark or meridian on the pen barrel from the nominal 'up' direction which may be constructed by a ray perpendicular to the pen barrel (somewhere not at the tip) and intersecting a pure-Z ray arising from the surface of the pen passing through the tip. This angle is measured in a clockwise direction when viewing the pen barrel from tail to tip, in degrees."
============
Comment #32:
------------
Width specification may be ambiguous

The direction of a trace through a sample point is undefined. You only have a discrete sequence of Cartesian samples.

Better to describe traces with 'width' data as the envelope of a sequence of circular dots of diameter given by the 'width' data. The trace generated by a circular brush of varying diameter.
------------
Resolution: accepted
------------
Changed the definition of 'Width' to "It is the diameter of the larger circle that can be inscribed within the trace locus."
============
Comment #38:
------------
Extra 's' in values

In:
<quote
cite= http://www.w3.org/TR/2006/WD-InkML-20061023/#traceContents >

Additionally, wsp may occur anywhere except within a decimal or hex and must occur if required to separate two values.
</quote>

There is a redundant terminal 's' in the last word.
------------
Resolution: accepted
------------
Removed the extra 's'.
============
Comment #39:
------------
Roll-your-own BNF -NOT

If the BNF you are using
http://www.w3.org/TR/2006/WD-InkML-20061023/#trace is a subset of the EBNF used in XML
http://www.w3.org/TR/2000/REC-xml-20001006#sec-notation please say so.

Compare with
http://www.w3.org/TR/SVGMobile12/refs.html
------------
Resolution: accepted
------------
Changed the spec to explicitly state that the EBNF used in the InkML spec is the subset of EBNF defined by the XML spec.
============
Comment #46:
------------
Type technicalities with timing attributes on <trace>

<quote
cite= http://www.w3.org/TR/2006/WD-InkML-20061023/#trace >

duration = xsd:decimal
The duration of this trace, in milliseconds.
Required: no, Default: unknown

timeOffset = xsd:decimal
The relative timestamp or time-of-day for the start of this trace, in
milliseconds.
Required: no, Default: unknown
</quote>

'undefined' is not a legal value of xsd:decimal

You need to roll this out in different prose. When the attribute
is not present, no information is given as to the time that this
ink appeared. 'Default' has a slightly different semantic than
this, If there is a default, it is a legal value that is true even
when stated.

Suggestion:

For @duration, let the default be zero. (data valid at one time)

For @timeOffset, say Default: none.
------------
Resolution: accepted
------------
Changed the default value of @duration and @timeOffset from Unknown to None..
============
Comment #80:
------------
Inspecting the shared canvas

This is not a change suggestion for the InkML specification _per se_, but rather raising a concern that we have in accessibility that it
would seem you will also have to worry about to make Ink-using
applications consistently usable in their look and feel so as to be
accepted by users. To co-exist with other sources in a shared canvas, you need to know what they are doing in all the dimensions of display phenomena that you enter yourself.

InkML Reference:
http://www.w3.org/TR/2006/WD-InkML-20061023

Issue Reference:
Find "actual presentation properties" in (Member confidential link)
http://lists.w3.org/Archives/Member/w3c-wai-pf/2006OctDec/0144.html

Client-side scripts that attempt to meet accessibility guidelines by assuring color contrast between the effects they control and the surrounding background color of the canvas have run into problems when:

>The CSS cascade resolves to 'clear' but there is a background color or image that shows through -- layered by the operating system outside the control of the CSS-driven rendering engine.

Applications that share multi-user ink traces with platform imagery
on a common canvas will encounter similar problems. The application will be color-coding the traces; and it will need to be concerned to allocate colors to the traces that will not only distinguish one trace from another but likewise be perceivable against the background arriving on the canvas from other sources.

http://www.w3.org/TR/WCAG20/guidelines.html#visual-audio-contrast

We can't expect all the other content painting on the canvas to get
transcoded into InkML but we should expect full information in some
common canvas coordinates. In addition, one should be able to inspect starting from the underlying object model which is the origin of other-source canvas effects, as in HTML+CSS.

There are similar problems with locations on the canvas. One common function of ink traces in whiteboard usage cases is to hook something in the background scene to attach an annotation. For this to work reliably, the final ink placement of the rendered text or other DOM objects must be knowable, reliably and accurately.

>Brad A. Myers, Choon Hong Peck, Jeffrey Nichols, Dave Kong, and Robert Miller. "Interacting At a Distance Using Semantic Snarfing," In Proceedings of Ubicomp 2001. Sept 30-Oct 2, Atlanta, Georgia. pp. 305-314. http://www.cs.cmu.edu/~pebbles/papers/pebblessnarfubicomp.pdf

This is not anything that impacts the definition of the Ink format, but it is something that impacts the success of Ink-using applications.

Please join with the WAI and the Working Groups working on the DOM and Delivery Context Interfaces to secure and ensure full and accurate access to this information about content rendered to the canvas.

Comment: We prefer to leave the 'anchoring' idea for the application developer to take care. But we might consider the 'rendering' aspects. We will go through this issue description in detail to decide on what the spec may need to support.
------------
Resolution: accepted
------------
Added clarifying statement to this effect: Its legitamite for a host app to have an accessbilty mode or alternate rendering mode where the explict color values in the InkML are reinterpretted to other colors for better accessiblity or suitablity of the rendering device.  Color to black and white for example.

Added the clarification to section 3.1.5 Color Channels.

Received on Monday, 30 August 2010 06:31:34 UTC