- From: Tom Underhill <Tom.Underhill@microsoft.com>
- Date: Mon, 11 Oct 2010 00:58:21 +0000
- To: Janina Sajka <janina@rednote.net>
- CC: "www-multimodal@w3.org" <www-multimodal@w3.org>, "smwatt@gmail.com" <smwatt@gmail.com>
Hi Janina, The Ink WG would like to have on record if you agree or disagree with the our responses to the comments below so that we can move forward to the Candidate Recommendation stage. Could you please respond before October 24th (two weeks from today). After that date we will assume that you accept our responses to the comments. Thank you! -----Original Message----- From: Tom Underhill Sent: Sunday, August 29, 2010 5:13 PM To: 'Janina Sajka' Cc: 'www-multimodal@w3.org'; 'smwatt@gmail.com' Subject: [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, 11 October 2010 00:58:58 UTC