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

Hello Tom,

Sure, I accept the resolutions to my comments 6, 7, 15, 41, 47, 81 and 110
as quoted below.

You're welcome, regards,
Gregory.

2010/12/1 Tom Underhill <Tom.Underhill@microsoft.com>

>  Thank you Gregory.   For the purposes of W3C’s record keeping could you
> please reply, cc www-multimodal@w3.org, and state that you accept the
> resolutions to your comments below.
>
>
>
> Thank you!
>
> Tom
>
>
>
> *From:* Grégory Pakosz [mailto:gpakosz@visionobjects.com]
> *Sent:* Wednesday, December 01, 2010 5:48 AM
>
> *To:* Tom Underhill
> *Subject:* Re: [ink] Responses to your comments on the W3C InkML Working
> Draft
>
>
>
> Hello Tom,
>
>
>
> Suggested revisions look fine to me.
>
>
>
> Regards,
>
> Gregory
>
> 2010/11/28 Tom Underhill <Tom.Underhill@microsoft.com>
>
> Hi Gregory,
>
>
>
> Stephen and I finally were able to meet and come to a resolution to
> comments #6 and #7.   Below are all the comments and our responses.   If you
> accept these changes, then I’ll reply with this to the public MMI list.
>
>
>
> Thank you!
>
> Tom
>
>
>
> ============
>
> *Comment #6:*
>
> ------------
>
> Efficiency of Searching for Retrieving the archived handwritten notes
> This way of searching handwritten notes is far from being efficient. If the
> annotation associated with a piece of ink comes from an incorrect
> handwriting recognition result, you would never recover. Modern digital ink
> searching rather "tries to recognize what you are looking for" among all
> your digital handwritten notes. To speed up the search process, the
> handwriting recognition process is split into parts that can be serialized
> and used as preprocessing stages for later ink searching. The result of this
> preprocessing is stored as index files that only need to refer to the actual
> trace data for search result presentation needs: for instance displaying a
> dialog box that render an excerpt of the ink. However, trace data is not
> useful at all for the search process itself.
>
> ------------
>
> Resolution: rejected
>
> ------------
>
> Interesting Question. This issue need not to be addressed as it is out of
> the scope of the standard.
>
> ------------
>
> Disagree.
>
> Indeed, this isn’t the scope of InkML to detail how to efficiently search
> through digital ink. However, as I said, associating a piece of ink with a
> tag that would come from some handwriting recognition process is just not
> state of the art.
>
> “The tags are typically text strings created using a handwriting
> recognition system.”
>
> No they’re likely not; just drop the handwriting recognition part and the
> previous sentence is still fine.
>
> “A software application may allow users to archive handwritten notes and
> retrieve them using either the time of creation of the handwritten notes or
> the tags associated with keywords.“
>
> Also, “or the tags associated with keywords” part is a bit blurry. Tags are
> keywords and then are likely to be associated with traces. Anyway, in this
> blogs and Evernote area, everybody knows and uses tags :)
>
>
>
> *From Tom: Agreed, below is the revised language in section 1.1*
>
> ·         *Ink Archiving and Retrieval*
>
> A software application may allow users to archive handwritten notes and
> later retrieve them by a variety of mechanisms.   using either the time of
> creation of the handwritten notes or the tags associated with keywords. The
> tags are typically text strings created using a handwriting recognition
> system.
>
> ============
>
> *Comment #7:*
>
> ------------
>
> Data Entry for Electronic form filling in keyboard less devices
> InkML in itself has no value proposition for digital form processing
> solutions: it offers no markup that targets the structure of a digital form
> like "here is a boxed field that is composed of 10 boxes in which the user
> is supposed to write his last name" ... As a consequence, you need to
> introduce additional markup that is likely to be application specific and
> thus fails to answer interoperability needs.
>
> ------------
>
> Resolution: rejected
>
> ------------
>
> The Spec recommends the application to use InkML as one of the XML data
> representation format and do not claims any support for application specific
> support.
>
> ------------
>
> More or less disagree.
>
> “In support of natural and robust data entry for electronic forms on a wide
> spectrum of keyboardless devices, a handwriting recognition engine developer
> may define an API that takes InkML as input.”
>
> The sentence kinda express InkML conveys enough information to achieve
> robust input in forms processing solutions. Pure trace data without semantic
> information is just not enough. As far as I can recall, HP had to extend
> InkML in their HP FAS solution and it looks like someone felt the needs to
> create UPX.
>
> Which makes me conclude that maybe the paragraph should be entitled “Uses
> of digital ink where InkML helps” instead of “Uses of InkML”.
>
> * *
>
> *From Tom: Agreed, below is the revised language in section 1.1*
>
> ·         *Electronic Form-Filling*
>
> In support of natural and robust data entry for electronic forms on a wide
> spectrum of keyboard-less devices, a handwriting recognition enginedeveloper may define an API that takes InkML as input for
> fields of the form.
>
> ============
>
> *Comment #15:*
>
> ------------
>
> Reference:
> http://www.w3.org/TR/2006/WD-InkML-20061023/#inkElement
> Why using a specific "documentID" attribute? Why not using xml:id?
>
> ------------
>
> Resolution: rejected
>
> ------------
>
> It will be solved by the solution of the above issue (Section 2.1, #14).
>
> ------------
>
> ???
>
> “It will be solved by the solution of the above issue (Section 2.1, #14).”
>
> What’s above issue?
>
>
>
> *From Tom: this is issue #14:*
>
> ============
>
> 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.
>
> *Looking at issue #14 again I see its only related in that it also talks
> about the documentId attribute.   I agree that xml:id would have been a
> better, more consistent choice, but it’s too late now – implementations
> exist that implement documentId. *
>
> ============
>
> *Comment #41:*
>
> ------------
>
> If no <traceFormat> is specified, the following default format is assumed:
> <traceFormat xml:id="DefaultTraceFormat">
> <channel name="X" type="decimal"/>
> <channel name="Y" type="decimal"/>
> </traceFormat>
>
> Does it mean that the "#DefaultTraceFormat" relative URI can be used as
> part of a traceFormatRef attribute or is it just an example of how the
> implicit trace format definition would look (see default trace format)?
>
> ------------
>
> Resolution: rejected
>
> ------------
>
> Muthu, 04/02/07
> Yes. It is explicitly specified in the case of Context in Section 4.5 given
> as below,
> The default context may be explicitly specified using the URI
> "#DefaultContext".
>
> ------------
>
> Disagree?
>
> The issue (well it was just a question) is marked as Rejected and the
> resolution refers to 4.5 The Default Context wich doesn’t adress my initial
> concern: search “DefaultTraceFormat” into
> http://www.w3.org/TR/2006/WD-InkML-20061023/ and you find nothing but an
> example.
>
> Anyway, in the latest draft of the specification, it looks like things have
> been sorted out since 3.1.1 <traceFormat> element explicitly states:
>
> The default trace has the reserved id "DefaultTraceFormat" and may be
> explicitly referenced using the URI "#DefaultTraceFormat".
>
> *From Tom: We just called it “rejected” in the sense that no change was
> made in the spec in response to the comment.   I will change it to
> “accepted” and reference more clearly the “DefaultTraceFormat” in section
> 3.1.1.*
>
> ============
>
> *Comment #47:*
>
> ------------
>
> The type attribute of a <trace> indicates the pen contact state (either
> "penUp" or "penDown") during its recording. A value of "indeterminate" is
> used if the contact-state is neither pen-up nor pen-down, and may be either
> unknown or variable within the trace. For example, a signature may be
> captured as a single indeterminate trace containing both the actual writing
> and the trajectory of the pen between strokes.
>
> The "type" attribute overlaps the definition of the reserved S channel for
> tip switch state (touching / not touching the writing surface).
> Now that the "type" attribute exists, a <trace> element can have its "type"
> attribute set to "penDown" while the actual trace data contains information
> about the tip being up or vice-versa! In such a case, I guess that it is up
> to the application to decide how to interpret the InkML file which by
> definition breaks interoperability.
>
> The default trace format could have defined an intermittent boolean S
> channel that defaults to true == pen down:
> The reader does not know the answer until reading the 4.3.1 <brush> element
> section:
> Same question goes for a continuation trace that has the "continuation"
> attribute set to "begin" while the "priorRef" attribute is defined
> It really seems that the <trace> element model is not robust enough in the
> sense that it permits undefined or application specific behavior.
>
> ------------
>
> Resolution: rejected
>
> ------------
>
> As per the guideline, the value of the S channel will override the pen type
> value.
>
> ------------
>
> Disagree.
>
> “As per the guideline, the value of the S channel will override the pen
> type value.”
>
> I’m sorry but I can’t find anything that asserts the value of the S channel
> is supposed to override the type attribute of the <trace> element.
>
> It looks like my original remark still applies: the default trace format
> could have defined an intermittent boolean S channel that defaults to true
> == pen down.
>
> Finally, it doesn’t answer the original question: what’s with a
> continuation trace that has the "continuation" attribute set to "begin"
> while the "priorRef" attribute is defined? It looks like it just have to be
> ignored.
>
> *From Tom: you are correct, there is no language about the S Channel
> overriding the pen type value.   We will add the clarification to the spec.
> *
>
> ============
>
> *Comment #81:*
>
> ------------
>
> <canvas xml:id="DefaultCanvas">
> <traceFormat>
> <channel name="X" type="decimal" default="0" orientation="+ve" units="em"/>
> <channel name="Y" type="decimal" default="0" orientation="+ve" units="em"/>
> </traceFormat>
> </canvas>
> It is not specified whether or not referring to the default canvas using a
> "#DefaultCanvas" relative URI is legal.
>
> ------------
>
> Resolution: rejected
>
> ------------
>
> It is legal. Issue is similar to issue #75 in Section4.5.
>
> ------------
> Disagree.
>
> Should have been set to accepted with a similar resolution to issue 75
> since the reviewed version of the specification was silent about it.
>
> It’s fixed in the latest draft anyways so it’s fine.
>
> *From Tom: We just called it “rejected” in the sense that no change was
> made in the spec in response to the comment.   I will change it to
> “accepted”.*
>
> ============
>
> *Comment #110:*
>
> ------------
>
> Headers ids naming convention is inconsistent.
>
> ------------
>
> Resolution: rejected
>
> ------------
>
> There are external links that refer to the #id's.  Changing the naming now
> would break external links.
>
> ------------
>
> Disagree.
>
> Could have been handled at the server level with redirects. And those
> external links refer to draft anyways (not to mention those which faded out
> during those 4 years).
>
> And Issue #126 resolution is a living example of an id which has been
> changed.
>
> *From Tom: I did make a concerted attempt to clean up the id’s to make
> them more consistent, but found several external docs that referenced the
> id’s (our own InkML XSD is one example, Microsoft Office implementation
> documentation is another one).   The instance in comment #126 I chose to
> rename because I couldn’t find any external references to it and it didn’t
> match the human readable name of the section anymore. *
>
>
>
>
>
> -----Original Message-----
> From: Grégory Pakosz [mailto:gpakosz@visionobjects.com]
>
> Sent: Friday, November 05, 2010 9:19 AM
> To: Tom Underhill
> Subject: Re: [ink] Responses to your comments on the W3C InkML Working
> Draft
>
>
>
> Hello Tom,
>
>
>
> 2010/11/5 Tom Underhill <Tom.Underhill@microsoft.com>:
>
> > Hi Gregory.   Sorry for the delay.   I've answered 5 of your
>
> > responses, but I am waiting for my co-editor Stephen to answer the
>
> > other two.   Below are my 5 responses are below.   I’m pushing for
>
> > Stephen to figure out the other two as they are more in his area.
>
> >
>
>
>
> No worry, I was just worried you didn't get my answers in time because we
> suffered several serious email drops lately: there were two weeks where I
> didn't really know who got my emails and who didn't. It would have been a
> pity to miss the October 24th "deadline" for such lousy reasons.
>
>
>
> >
>
> > Regarding your attribution on the spec: I have added your name to the
>
> > Authors list and it will appear in the next working draft.   And I
>
> > fixed VisioObjects to Vision Objects in the Disposition of Comments
> document.
>
> >
>
> >
>
>
>
> Thank you for that. I'm glad this project is live and kicking again.
>
>
>
> I'll send you back my comments (if any) as soon as Stephen has found time
> to reply to the remaining two comments.
>
>
>
> Do not hesitate to contact me if needed.
>
>
>
> Regards,
>
> Gregory.
>
>
>
>
>
>
>