W3C home > Mailing lists > Public > www-multimodal@w3.org > October 2010

RE: [ink] Responses to your comments on the W3C InkML Working Draft

From: Tom Underhill <Tom.Underhill@microsoft.com>
Date: Mon, 11 Oct 2010 01:01:23 +0000
To: Robert Vincenz <vincenz@snafu.de>
CC: "www-multimodal@w3.org" <www-multimodal@w3.org>, "smwatt@gmail.com" <smwatt@gmail.com>
Message-ID: <4045AB4EE43EB94C9508DDC490FA9F7127CBE300@DF-M14-02.exchange.corp.microsoft.com>
Hi Robert,

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:16 PM
To: 'Robert Vincenz'
Cc: 'www-multimodal@w3.org'; 'smwatt@gmail.com'
Subject: [ink] Responses to your comments on the W3C InkML Working Draft

Thank you for your comments on the InkML Working Draft.   The InkML working group has considered each of your comments and have recorded them and our responses 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 each of your 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/ .

The original copies of your comments made on 2010-06-09 are here: http://lists.w3.org/Archives/Public/www-multimodal/2010Jun/0001.html 

Thank you for your input!

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

============
Comment #177:
------------
2.1 <ink> element -> http://www.w3.org/TR/2010/WD-InkML-20100527/#inkElement
For all but the documentID you give the require and default information.
------------
Resolution: accepted
------------
The required/default was at the *end* of section 2.1.  Move it up with the attribute to match all the other attributes in the spec.
============
Comment #178:
------------
( definitions   | context  | trace  | traceGroup  | traceView  | annotation  | annotationXML  )*'
this should be
'trace ( definitions   | context  | trace  | traceGroup  | traceView  | annotation  | annotationXML  )*'
So that there MUST be one trace Element.
------------
Resolution: accepted
------------
Agreed: at least a single <trace> is required.  Update the XSD as well.
============
Comment #179:
------------
Because this can be used in situation where the date of creation/capturing is important you should also proved a optional date Attribute.
------------
Resolution: rejected
------------
A data attribute on <ink> would be redundant: we already have the <timestamp> element and timestamp attribute on trace.
============
Comment #180:
------------
3.1.1 <traceFormat> element -> http://www.w3.org/TR/2010/WD-InkML-20100527/#traceFormat
In the last line'The default trace format may be explicitly specified using the URI "#DefaultTraceFormat".  The application defines the default trace format.'This Element have no URI as attribute or content so do you mean the ID or is this URI used in a different place and mean a not defined traceFormat definition? If this is a URI that is used in a other Element pleas name them or move this line to this Elements description.
------------
Resolution: accepted
------------
Clarified the paragraph:

The <context> element may use the traceFormatRef attribute to refer to a <traceFormat> by it's id.  If no <traceFormat> is specificed in an InkML file, an application defined default trace format is used.  The default trace has the reserved id "DefaultTraceFormat" and may be explicitly referenced using the URI "#DefaultTraceFormat".
============
Comment #181:
------------
3.1.2 <intermittentChannels> element -> http://www.w3.org/TR/2010/WD-InkML-20100527/#intermittentChannels
To avoid misinterpretation you MUST define that the intermittentChannels MUST NOT be followed by a normal channel definition. Because in this cases the order is not clear. I also recommit to change this Element definition place to be after the one of the channel Element.
------------
Resolution: accepted
------------
I swapped the order of sections 3.1.2 and 3.1.3 -- that makes more sense.  The Contents of <traceFormat> does indicate that intermittentChannels must appear after channels, as does the XSD, as does the langugages of section 3.1.3 (the new section 3.1.3) which says:

"The <intermittentChannels> section is optional and must appear after the regular <channel> elements (if any) within a <traceFormat> element.
3"
============
Comment #182:
------------
3.1.3 <channel> element -> http://www.w3.org/TR/2010/WD-InkML-20100527/#channel
Is the name attribute value case sensitive interpreted?
------------
Resolution: accepted
------------
Yes, they are case sensitive.  I added language to say they're case sensitive.
============
Comment #183:
------------
The most pens give a value that DO NOT present a mass but a relative value(0 for not pressed up to a a max value like 256 or 1024 that represent the max measured press or more). So why is g(gram) used? I recommit to use a percentage value or a decimal from .0 to 1. As alternate split it to F for force with percentage or .0 to 1 and G for a mass in gram.
------------
Resolution: accepted
------------
Yes, that makes a lot of sense since I have never seen a device that actually uses a mass to record force, it's a always a arbitrary value range.  Even though we specify a default, a 'F' channel may still be defined with a particualar unit such as grams, newtons, etc.
============
Comment #184:
------------
For the orientation attribute is what is +ve? Increase or decrease?
------------
Resolution: rejected
------------
+ve' is increasing for a particular direction, depending on X,Y, or Z as described in the channel table:

X coordinate. This is the horizontal pen position on the writing surface, increasing to the right for +ve orientation.
Y coordinate. This is the vertical position on the writing surface, increasing downward for +ve orientation.
Z coordinate. This is the height of pen above the writing surface, increasing upward for +ve orientation.
============
Comment #185:
------------
3.1.5 Color Channels -> http://www.w3.org/TR/2010/WD-InkML-20100527/#color
What is the value range of CR, CG, CB, CC, CM, CY and CK or is a mapping element required for the range? This Range SHOULD be definable because the Color-space size for professional graphic programs can be 8, 10, 12, 16, 32 bit per channel(e.g. http://www.cinepaint.org/).Maybe the Color channels should be defined more free to allow more color-spaces like YUV, CIE, ...
------------
Resolution: rejected
------------
Yes, a mapping would define the actual min/max values for each channel (0-255, or 0.0-1.0, etc.).   Since user defined channels are possible, other color spaces can be application defined.
============
Comment #186:
------------
3.1.7 Time Channel -> http://www.w3.org/TR/2010/WD-InkML-20100527/#time
The "(see Time Channel)" is a self-reference. Why? Do you mean the timestamp element?
------------
Resolution: accepted
------------
Removed the useless reference.  It was a hold over from when this paragraph lived elsewhere.
============
Comment #187:
------------
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>.'This is the first time the inSource element is named. Which other predefined channels are affected?
------------
Resolution: accepted
------------
The meaning is really defined by the <traceFormat>.  <traceFormats> may live in an <inkSource>.  Earlier versions of the spec may have requried <traceFormats> in <inkSources> and hence this language.  I reworded it to:

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 trace's associated <traceFormat>. In the case of the time channel, its <channel> element contains both a units and respectTo attribute.
============
Comment #188:
------------
3.1.9 Specifying Trace Formats -> http://www.w3.org/TR/2010/WD-InkML-20100527/#specifying'
Thus, in the simplest case, an InkML file may contain nothing but <trace> elements.'
That not correct. As you wrote in 1.2'All content of an InkML document is contained within a single <ink> element.' This is also required to be XML conform. What you mean is:"Thus, in the simplest case, an InkML file may contain nothing but <trace> elements insite a <ink> element."
------------
Resolution: accepted
------------
Changed to:

Thus, in the simplest case, an InkML file may contain nothing but <trace> elements within an <ink> element.
============
Comment #189:
------------
3.2.1 <trace> element -> http://www.w3.org/TR/2010/WD-InkML-20100527/#trace'Extended Backus-Naur Form (EBNF)'There is no reference to the RFC or other document that defines EBNF and the one provided is not this good.
trace   ::= point ("," point)* ","? wsp*
point   ::= (wsp* value)+ wsp*
value    ::= difference_order?  wsp* "-"? wsp* number | "T" | "F" | "*" | "?"'
This is wrong. Because this allows:
1) negative values for coordinate values
2) a point to be only made with one value
3) you can prefix the T F * and ? with -
4) write two values without space( 1 2 -> 12). 
you have wrote this already after the EBNF, but why using EBNF and then tell the reader to ignore it?
5) difference order for F T * and ?6) ? for regular values
7) mix of regular and intermittent values
------------
Resolution: accepted
------------
Changed the EBNF reference to:

The following grammar defines the syntax of the data that appears within a <trace> element.  It is described using the subset of Extended Backus-Naur Form defined in the Notation section of the Extensible Markup Language (XML) 1.0 (Fourth Edition) specification [EBNF].  This subset of EBNF includes the following notation:

It is recongnized that the grammar presented is not perfect, but is the closest validation possible using BNF and still remain brief and human readable.
============
Comment #190:
------------
If the continuation attribute is not present, is then the trace presenting a complete one?
In the case of a trace with a continuation attribute with "begin" or "middle" is followed by a trace without continuation, how is this to interpret or is this not allowed? Must a "multi trace" finished/closed with a trace element with a continuation attribute with the value "end"?
------------
Resolution: rejected
------------
Yes, if there is no continutation attribute, then the trace is a self-contained trace.

The relative order of <trace> elements is not relevent.  As the spec states, if a continuation attribute is present, and is "middle" or "end", it must have a priorRef attribute that references the prior trace.

a multi-trace doesn't have to have an explicit "end" trace.   Multi-trace components don't necessarily have to in the same <ink> document.   A possible application could be a "stream" of traces coming from a server to a client, in chunks -- each chunk being a seperate <ink> document.   the order that the chunks arrive at the client could come in any order.  The client would assemble the mulit-trace into a single trace as it receives the chunks.
============
Comment #191:
------------
Type attribute definition: 'A value of "indeterminate" is used if the contact-state ... and may be either unknown or variable within the trace.'
The change of penup/pendown should force to a new trace. If the trace is of none contact(between pen and digitizer) it is pen up. If the pen is in contact with the digitizer it is pendown. In the example you give it is important to know if the pen has contact at tracing time or not and there is no other way to define this state. And i see no use case where a mix of pendown/penup is of no relevance or where the state can't be determined(the unknown state).
------------
Resolution: rejected
------------
If the trace is a mid-trace in a set of trace continuations, the state can be "indeterminate".  Its actual "penUp" or "penDown" state is determined by a prior trace.
============
Comment #192:
------------
'Regular channels may be reported as explicit values, differences, or second differences: ...'What is a second difference? Does this mean that a second difference is refer to the same as a preceding difference or to the difference?
------------
Resolution: rejected
------------
Its another way of saying it's a "first order derivative" or "second order derivative".  Or,  no difference == absolute coordinate, first order == velocity, second order == acceleration.
============
Comment #193:
------------
'Intermittent channels may be encoded with the wildcard character "?".' and'All regular channels must be reported, if only with the explicit wildcard "?".'Because of the first line i cite i think the second is not right. The only wildcard allowed for regular channels is the *.
------------
Resolution: accepted
------------
Agreed.  Changed the wildcard from '?' to '*'.
============
Comment #194:
------------
If any intermittent values are reported for the point, they are given next, in the order given by the <intermittentChannels> elements of the applicable <traceFormat>. Unreported intermittent channels are interpreted as though they were given by the wildcard "*".'This definition make it not clear if it is allowed to leave any channels away, when one is given. So here two questions :
1) is it OK to leave the channels away that follow the channel you give a value? (as i can see in the example it is OK) 2)is it OK to leave channels away before the one you give(that is not OK -> misinterpretation, but you do not forbid it)'
If any intermittent values are reported for the point, they are given next, in the order given by the <intermittentChannels> elements of the applicable <traceFormat>. Only intermittent channels that follows the last explicit given channels can be give away and are interpreted as though they were given by the wildcard "*".'
------------
Resolution: rejected
------------
I believe the core issue is this: For a regular or intermittent channel, if a trace provides nothing but wildcards or nothing for a given channel, what is its value?  The simple answer is 0 or F, depending on its data type.   This is in fact what the Microsoft Office implementation does.

I don't feel this needs to be explicitly stated in the spec.
============
Comment #195:
------------
In the table that explain the example is something wrong on row 3("7"-8) or 4(3-5). I can't say which one because the second difference is not clear.If the second difference is the difference to the difference than is row 4 wrong(3-5) or there is no need for a second difference because this is the same as a numeric value.If the second difference is the difference to the value before the difference, then the 3th row is wrong("7"-8 | 1132 | 18424 | ...).  In the same table every thing is the difference to the previews values and not the absolute values. But i can't see why this is so. Is the default to interpret the values relative? Then the example in 1.2 is wrong because there is the values interpreted as absolute coordinates.
------------
Resolution: rejected
------------
It is correct.  The first difference is a velocity (vx, vy), the second difference is an acceleration (dvx, dvx).

The first row is an absolute x,y pair: 1125, 18432.
The second row is a first order derivative, or a velocity, or change in value from the previous row.  So 1125+23=1148, 18432+43=18475.
The third row (and all subsequent rows) are second order derivatives, or accelerations, or changes in velocity from the previous row.  So 1148+(23+7)=1178, 18475+(43+-8)=18510.
and so on down the table.
============
Comment #196:
------------
'Note: see Appendix A Implementation Guidelines for information about reducing file or stream size.'Appendix A is "Acknowledgements". You mean Appendix B.
------------
Resolution: accepted
------------
Changed the reference from Appendix A to Appendix B.
============
Comment #197:
------------
3.3.2 <traceView> element -> http://www.w3.org/TR/2010/WD-InkML-20100527/#traceViewElement
In the example the cascades of tracegroup elements is keep as in the origin. But i can't see this in the description. Must the cascades keep as in the source?  the second traceview element of L3 has the "4:1:1" value for the to attribute. In the description under the example is "4:1:1:2" written, which is right for the given output.
------------
Resolution: rejected
------------
You are correct.  No clarification needed in spec.
============
Comment #198:
------------
I#m not sure what is with a 0 in a to or from attribute value:
e.g.<ink><trace xml:id="t1">1 2, 3 4, 5 6</trace><traceView traceDataRef="t1" to="0:2" /></ink> what is right?
1) it's not right because the index starts with 1
2) <trace> 1 2, 3 4</trace>
3) <trace xml:id="t1">1 2, 3 4, 5 6</trace>

If it is 1 the example in the Draft is right, but you cant select values in a document with only one ink, one trace and traceView elements.
The 2 mean its not a consistent numbering(elements can start with 0 but points start with 1).
3 means the examples in the Draft are wrong, but you can select points in my example and its a consistent numbering.
------------
Resolution: rejected
------------
A '0' in either the to or from attribute is illegal.  This section explicilty states that the indexes are 1-based.  0 is an error.
Received on Monday, 11 October 2010 01:01:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 11 October 2010 01:02:00 GMT