[ink]Last Call typos and errors in Chapter 1 to 3(inclusive)

Hello everyone,

I'm not a native English people so sorry for my bad English. I found 
some typos and errors on the Last Call of the IncML from 27 May 2010 
(http://www.w3.org/TR/2010/WD-InkML-20100527/) .

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.

'( 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.

Because this can be used in situation where the date of 
creation/capturing is important you should also proved a optional date 

3.1.1 <traceFormat> element -> 
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.

3.1.2 <intermittentChannels> element -> 
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.

3.1.3 <channel> element -> 
Is the name attribute value case sensitive interpreted?
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.

For the orientation attribute is what is +ve? Increase or decrease?

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, ...

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?

'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?

3.1.9 Specifying Trace Formats -> 
'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."

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
'trace                 ::= first_point ("," more_points)* ","? wsp*

first_point            ::= wsp* coordinate_values
                            ( wsp* regular_value+ wsp*
                             intermittent_value* )? wsp*

more_points            ::= wsp* (coordinate_values | relative_coord)
                            ( regular_value* wsp* intermittent_value* )

coordinate_values      ::= number wsp number

relative_coord         ::= "-"? wsp* number ( "-" wsp* ) | wsp+ ) number

regular_value          ::= ( ( difference_order? ( ( "-" wsp* ) | wsp+ )
                            number ) | "*" ) wsp*

intermittent_value     ::= ( regular_value | "?" | boolean ) wsp

boolean                ::= "T" | "F"

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"?

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).

'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?

'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 *.

'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 "*".'

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.

'Note: see Appendix A Implementation Guidelines for information about 
reducing file or stream size.'
Appendix A is "Acknowledgements". You mean Appendix B.

3.3.2 <traceView> element -> 
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.

I#m not sure what is with a 0 in a to or from attribute value:
<trace xml:id="t1">1 2, 3 4, 5 6</trace>
<traceView traceDataRef="t1" to="0:2" />
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.

Thats all for the moment. I hope i find the Time to check the other 

Robert Vincenz

Received on Thursday, 10 June 2010 06:41:47 UTC