- From: Tom Underhill <Tom.Underhill@microsoft.com>
- Date: Mon, 11 Oct 2010 00:59:59 +0000
- To: Grégory Pakosz <gpakosz@visionobjects.com>
- CC: "www-multimodal@w3.org" <www-multimodal@w3.org>, "smwatt@gmail.com" <smwatt@gmail.com>
Hi Grégory, 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:14 PM To: 'Grégory Pakosz' 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 2006-12-20 are here: http://lists.w3.org/Archives/Member/w3c-mmi-wg/2007Jan/0027.html Thank you for your input! The InkML Editors: Tom Underhill, Microsoft Stephen M. Watt, University of Western Ontario ============ Comment #3: ------------ Application to handwriting recognition <<1. Overview, Paragraph 2 and 4 >> It is true that InkML allows the capture of ink as the user composed it, however in the typical case of handwriting recognition, ink itself is barely usable. Another valuable piece of information is the conditions in which the ink has been written: what the user was supposed to write: a name, a date, a phone number? what is the language? was the handwriting zone constrained: boxes, lines? etc. ------------ Resolution: accepted ------------ Rephrased to explicitly say that the Digital Ink data can be represented in InkML format and it does not intend to provide support for capturing other information like the type of the data and type of the handwriting zone and etc. Added to the last paragraph: "It is not within the designed of InkML to describe and store semantic information, such as the plain text of ink recognized as handwriting. Nor is it a goal of InkML to store the contextual information about the ink, such as what kind of field in a form where ink was written. " ============ Comment #4: ------------ "InkML provides means for extension. By virtue of being an XML-based language, users may easily add application-specific information to ink files to suit the needs of the application at hand." At the cost of losing interoperability. Comment: Muthu May need to explicitly specify this fact. ------------ Resolution: accepted ------------ Rephrased: InkML can include XML from other schemas by using the AnnotationXML construct. Additionall, InkML could be embedded within other XML documents. ============ Comment #5: ------------ Ink Messaging: Application for mobile device users My opinion is that XML is generally speaking way too verbose for mobile application usage: anything that is XML based does not suit synchronous/streaming mobile scenarios because of the weight of XML parsers and the verbosity of the data. ------------ Resolution: rejected ------------ We have XML parsers for Win CE and J2ME platforms. We have support for issuing SOAP request to Web services from hand held. ============ 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. ============ 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. ============ Comment #8: ------------ Pen Input and Multi modal Systems : Cross-modal redundancy use of InkML Hmm right the InkML group is a subgroup of the MMI group Apart from that, please don't see any offence but I find this paragraph rather useless to the understanding of InkML. ------------ Resolution: accepted ------------ While it is obvious how InkML could participate in a multimodal framework, it was not made clear how it could benefit from a multimodal framework. We have therefore modified the multimodal paragraph in 1.1 to be more explicit how pen input can help multimodal environments and vice-versa. ============ Comment #9: ------------ "A sequence of traces accumulates to meaningful units, such as characters, words or diagrams." This particular sentence could make the reader think that InkML is able to describe the structure of handwriting which is not the case at all. Indeed, there is no markup capable of describing a typical boxed field on a digital form: position and dimensions of the boxes and more importantly to which box belongs which trace. ------------ Resolution: rejected ------------ By default, InkML do not have plan to support elements to describe characters/words/diagrams. But the application developer can achieve them using <annotation> or <annotationXML> elements under <traceGroup> (Semantic labeling traces as characters/words/diagrams). ============ Comment #10: ------------ Finally, the InkML specification is limited in scope: It is currently oriented to fixed Cartesian coordinate systems, it does not support sophisticated compression of trace data, and it does not support non-ink events (although the later could be handled via annotations). But would be application specific until a specification for a typical kind of annotation comes to light like it is the case for mathematical expressions represented by MathML markup. ------------ Resolution: accepted ------------ Clarification was added to section 3.1.8 to make explicit how non-ink events, other coordinate systems, etc can be captured in traces. ============ Comment #11: ------------ In: http://www.w3.org/TR/2006/WD-InkML-20061023/#OverviewModes "For ease of implementation, it is recommended that, in archival mode, referenced elements be defined inside a declaration block using the <definitions> element." I am sure this remark has some importance otherwise it would not be included in the specification. However at this point of the document, its meaning is unclear to a beginner. A concrete example would help. ------------ Resolution: accepted ------------ Muthu, 03/30/07 Yes. This is the first place where it is mentioned. We have this fact later referred in Section 4.5 "The Default Context", in Section 6.2 "Definitions" and Archival Applications section. Added internal links (see XXX) to these sections. ============ Comment #12: ------------ The media type of InkML document is application/inkml+xml. See the Media Type definition for details. This media type is expected to be registered with IETF. >>> Is the media type registered yet or does the sentence come from the original version of the document? ------------ Resolution: accepted ------------ Appendix B has been updated per the agreements made by the subgroup during the July 15, 2008 meeting: http://lists.w3.org/Archives/Member/w3c-mmi-wg/2008Jul/0041.html ============ 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). ============ Comment #16: ------------ If no <traceFormat> is specified, a default encoding format of X and Y coordinates is assumed. At this point of the document, is it clear that the default <traceFormat> is X then Y coordinates ? Somehow it would be good to emphasize the fact that coordinates are interleaved. ------------ Resolution: accepted ------------ Rephrased to explicitly state the default traceFormat is X followed by Y ============ Comment #22: ------------ Regular channels appear first in the <trace>, followed by any intermittent channels. Correspondingly, the <traceFormat> element contains an ordered sequence of <channel>s, giving the regular channels (if any), followed by an optional <intermittentChannels> section. The order of the coordinates in each point of a trace is determined by the order of the <channel> elements in the trace format, including those from the intermittent channels part. The section refers to the concept regular or intermittent channel that was described in the introduction (see 3.1 Trace Formats). Maybe I'm too French for this writing style but I feel like the reader has to go back and forth and back again before having a chance to grasp the whole thing :D Imagine you use the index to go to the <traceFormat> element definition, you read about channels but you have to scroll up to the introduction to know what they are. Then you scroll down where it talks about <channel>s that are followed by an optional <intermittentChannels> section which is described first! ------------ Resolution: accepted ------------ Rephrased to clarifity order of regular channels vs intermittent channels. ============ Comment #25: ------------ respectTo = xsd:anyURI Specifies that the values are relative to another reference point. Required: no, Default: none The respectTo attribute specifies the origin for channels of integer or decimal type. For time channels, this is given as a URI for a <timestamp> element. For other dimensions the meaning is application-dependent. I find this part of the <channel> element definition far from being clear (see 3.1.3 <channel> element): is it always an URI or only an URI when one wants to refer to a <timestamp> element? Please provide an example of the usage of the respectTo attribute applied to X and Y channels. Also, can the respectTo attribute be used when wanting to encode delta-x and delta-y coordinates? The following example defines a time channel whose values for a given point are the relative to the timestamp refered to to by #ts1: <channel name="T" type="integer" units="ms" respectTo="#ts1"/> Although a usage example of the respectTo attribute is given as part of the time channel description (see 3.1.7 Time Channel), it is unclear to what this #ts1 relative URI corresponds to. ------------ Resolution: accepted ------------ Rephrased to clarify respectTo attribute is the URI of a <timestamp> for time channels, but application defined for application defined channels. ============ Comment #29: ------------ It is often useful to record the sine of this angle, rather than the angle itself, as this is usually more useful in calculations involving angles. The <mapping> element can be employed to specify an applied sine transformation. At this point of the specification, it is unclear in which way it works. This is another example of back and forth reading (see 3.1.4 Orientation Channels). ------------ Resolution: rejected ------------ Yes. The context of going for a <Mapping> is explained in the last paragraph of 3.1.3, i.e. before 3.1.4. ============ Comment #33: ------------ relativeTo -> respectTo - rename: channelDef --> channel, relativeTo --> respectTo (in text and example) >>> Fixed Some references to "relativeTo" still present in text and example. ------------ Resolution: accepted ------------ Changed the remaining instances of 'relativeTo' to 'respectTo'. ============ Comment #34: ------------ 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. Again, this paragraph uses a feature that has not been introduced/detailed yet (see 3.1.7 Time Channel). ------------ Resolution: accepted ------------ Added a reference to the Time Channel section. ============ Comment #40: ------------ The appearance of a <traceFormat> element in an ink markup file both defines the format and installs it as the current format for subsequent traces (except within a <definitions> block). At this point of the document, it is unclear whether or not a <traceFormat> element is allowed as a child of the <ink> element. Indeed the definition of the <ink> element specifies that it can contain <definitions>, <context>, <trace>, <traceGroup>, <traceView>, <annotation>, or <annotationXML> elements but no <traceFormat> elements. At this point, the reader knows how the <traceFormat> markup has to be written but does not have any clue of where it belongs (see 3.1.9 Specifying Trace Formats). ------------ Resolution: accepted ------------ Added a reference to the Specifying Trace Formats section. ============ 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". ============ 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. ============ Comment #48: ------------ Also, the specification should give precise use cases for continuation traces. In archival mode, splitting a whole trace into continuation traces has no use (and it would not be difficult to produce correct markup, see above). But continuations traces are needed in the case of collaborating applications (streaming mode), e.g user 1 is writing on device A and the digital ink has to be dynamically replicated on the screen (device of user 2. Streaming mode side note: <trace id="t1" type="penDown" continuation="begin" ...>...</trace> <trace id="t2" continuation="middle" priorRef="#t1" ...>...</trace> <trace id="t3" continuation="end" priorRef="#t2" ...>...</trace> This would be the typical markup produced when being in streaming mode. In the use case described above, that is user 2 seeing what user 1 is writing, if you want a quick and smooth ink rendering on user 2's screen, then the amount of actual trace data will definitely be VERY SMALL compared to the amount of markup being produced, even when additional attributes are not taken into account. Also, I am not very familiar with XML streaming in general but I imagine that something like SOAP adds its own overhead. <trace id = "toBeSplit"> 1125 18432,'10 '22,'5 '7,'8 '23','10 '8 F,'5 '7,'2 '11,'7 '5 T,'10 '7 </trace> is likely to be split into <trace id="t1" type="penDown" continuation="begin">1125 18432</trace> <trace id="t2" continuation="middle" priorRef="#t1">'10 '22</trace> <trace id="t3" continuation="end" priorRef="#t2">'5 '7</trace> <trace id="t4" continuation="end" priorRef="#t3">'8 '23</trace> <trace id="t5" continuation="end" priorRef="#t4">'10 '8 F</trace> <trace id="t6" continuation="end" priorRef="#t5">'5 '7</trace> <trace id="t7" continuation="end" priorRef="#t6">'2 '11</trace> <trace id="t8" continuation="end" priorRef="#t7">'7 '5 T</trace> <trace id="t9" continuation="end" priorRef="#t8">'10 '7</trace> which has little chance of being very Bluetooth friendly ------------ Resolution: rejected ------------ The issue seems to be an implementation issue. Yes, the application in the above example add lot of InkML markup data overhead on wire and demand high processing power; may the user find a different solution to do solve the problem. We may not require to modify the specification for solving this issue. ============ Comment #49: ------------ If a continuation attribute is present, it indicates that the current trace is a continuation trace, i.e. its points are a temporally contiguous continuation of (and thus should be connected to) another trace element. The possible values of the attribute are: begin, end and middle. As far as I can recall the discussions that took place during the face to face meeting in NYC, "begin" "end" and "middle" are to be used when wanting to render the traces with the help of splines: obviously you computations differ depending on it is the beginning of the trace, the middle or the end. In fact it is all biased by the fact that InkML is supposed to be parsed by a standard DOM or SAX XML parser. With such a predicate, you cannot avoid having to cut traces into smaller pieces of valid markup. As a consequence, InkML is somehow forced to introduce the concept of data packets at the OSI application layer level, while existing network protocols like TCP/IP already take care of it. With a custom InkML parser one could imagine doing: "<trace>1125 18432," message is sent by user 1 and received by user 2. -- this is the beginning of the trace because there is a <trace> markup. "'10 '22, '5 '7," message is sent by user 1 and received by user 2. -- this is the middle of the trace because only coordinates are sent. ... "'10 '7</trace>" message is sent by user 1 and received by user 2. -- this is the end of the trace because there is a </trace> markup. ------------ Resolution: rejected ------------ . The issue seems to an implementation issue. Yes, the application in above example add lot of InkML markup data overhead on wire and demand high processing power; may the user find a different solution to do the same. . The spec may attempt to reduce the amount of mark up generation in this case. One idea is to replace the 'continution' attribute with a Boolean attribute to indicate the 'end' fragment. So all the 'trace' elements except the last one need not to have the 'continution' attribute. . The implementation specific discussions can be addressed in 'tutorials' like documents. ============ Comment #50: ------------ Note: the trace syntax defined here makes the InkML file sizes (as well as the XML DOM trees) smaller while keeping the benefits of XML. However some applications, for instance those concerned with transmitting InkML documents across the Web, might require even smaller file sizes. It is thus recommended (but not required) that InkML implementations support the gzip standard compression scheme (see [RFC1952]). I suppose you recommend supporting whole gzip compressed ".inkml.gz" files. Some Anoto pen manufacturer decided to use an XML based file format where the ink traces markup is compressed using a zip compression scheme then encoded in Base64 before being re-injected into the XML document: you reduce the amount of data by compressing but you increase it afterwards because of the Base64 encoding ... (see http://www.w3.org/TR/2006/WD-InkML-20061023/#traceContents 3.2.1 <trace> element contents]). Comment: The recommendation of the spec is a valid idea but may not be optimized. We need further investigation by looking at how does this requirement is solved in general and if there is an optimum technique for it. We may look in to how SOAP XML request in Web Services handled. ------------ Resolution: accepted ------------ Removed the "Note:" paragraph that suggest the use of 'gzip' from the specification. Added the resolution given in the message http://lists.w3.org/Archives/Member/w3c-mmi-wg/2007Dec/0021.html, as an appendix of the specification document. ============ Comment #51: ------------ contextRef = xsd:anyURI The context associated with this traceGroup. Required: no, Default: none brushRef = xsd:anyURI The brush associated with this traceGroup. Required: no, Default: none <traceGroup> element also defines "contextRef" and "brushRef" attributes: same question as for the <trace> element, what should we do when "contextRef" and "brushRef" are both defined but the "brushRef" or the <brush> of the corresponding <context> differs from the <traceGroup>'s "brushRef"? Actually the answer to this question seems to be given by a usage example in the 7.1 Archival Applications section. If a trace includes both brushRef and contextRef attributes, the brushRef overrides any brush attributes given by the contextRef (see 4.3.1 <brush> element section). Does it apply to <traceGroup> elements (see 3.3.1 traceGroup element)? ------------ Resolution: accepted ------------ Muthu, 04/02/07 Yes. The documentation has to be updated to explicilty state the order of precedence: brushRef's override any brushes contained in a contextRef. brushRef's and contextRef's on <trace>'s override any specifications on <traceGroup>'s. ============ Comment #55: ------------ The <traceView> element is used to group traces by reference from the current document or other documents. If a traceDataRef attribute is given, then a to and/or from attribute may be given. Together, traceDataRef, from and to refer to another element and select part of it. An traceDataRef attribute may refer to a <trace>, a <traceGroup> or another <traceView>. I do not really understand why the <traceView> element is itself a group. Why can't a <traceView> element be part of a <traceGroup>??? Why isn't a <traceView> just a view instead of being view+group ? <traceView xml:id="L3"> <traceView traceDataRef="#L1" from="2"/> <traceView traceDataRef="#L2" from="2" to="4:1:1"/> </traceView> Why can't it be: <traceGroup xml:id="L3"> <traceView traceDataRef="#L1" from="2"/> <traceView traceDataRef="#L2" from="2" to="4:1:1"/> </traceGroup> (see 3.3.2 <traceView> element contents and 3.3.2 <traceView> element examples). ------------ Resolution: accepted ------------ Yes, it would be have been a possible design to allow traceGroups to contain traceView's and thus require traceView's only as leaf elements. We could even have modified trace to have a traceDataRef and do away with traceView altogether. This would make handling traces and traceGroups more complicated however. ============ Comment #59: ------------ The context element both provides access to a useful shared context (canvas) and serves as a convenient agglomeration of contextual attributes. The context itself is not useful but at least it is convenient (see 4.1 The <context> element) ------------ Resolution: rejected ------------ The purpose of the <context> element explained in the specification is clear. There is no need for any conceptual change required in the documentation as action to the issue raised. ============ Comment #60: ------------ xml:id = xsd:ID The unique identifier for this context. Required: no (yes for archival InkML), Default: none I'm curious about the conditional part, how do you enforce this? How do you actually know the InkML document is intended for archival mode? Comment: Muthu, 04/02/07 There is no way to identify the type of Ink Document as Archival/Streaming and hence not possible to enforce this rule. We may have to add a new attribute called 'mode' to Ink document?? ------------ Resolution: accepted ------------ Set the 'Required' constraint to 'no' on @xml:id (remove the exception for archival case). ============ Comment #61: ------------ canvasRef = xsd:anyURI The URI of a canvas element for this context. Required: no, Default: "DefaultCanvas", or inherited from contextRef traceFormatRef = xsd:anyURI A reference to the traceFormat for this context. Required: no, Default: default trace format, or inherited from contextRef >>Is it "default trace format" or "DefaultTraceFormat"? I already asked the question but, could "#DefaultCanvas" and "#DefaultTraceFormat" relative URIs be used as references elsewhere, although they are implicitly defined? Comment: Muthu, 04/02/07 Yes. It is explicitly specified in the case of Context(Section 4.5) as given below, The default context may be explicitly specified using the URI "#DefaultContext". inkSourceRef = xsd:anyURI A reference to the inkSource for this context. Required: no, Default: default capture device, or inherited from contextRef >> What about default capture device? ------------ Resolution: accepted ------------ It is a documentation issue; it will be fixed. "DefaultCanvas" to "#DefaultCanvas" and "default trace format" to "#DefaultTraceFormat". ============ Comment #62: ------------ Each constituent part of a context may be provided either by a referencing attribute or as a child element, but not both. Thus it is possible to have either a traceFormatRef attribute or a <traceFormat> child element, but not both. Can an XML schema enforce this (see 4.1 The context element)? Proposal 1: May allow defining both the referencing attribute as well as child element. Then the ambiguity can be resolved by a guideline that the child element value will override the value derived from the referencing attribute. So the existence of both is equivalent to having child element alone. Resolution: Stephen: Normative English text that says "which one should be used" needed. Proposal 2: Remove the referencing attributes and always allow only child elements. The sample usages are given below, Example 1: To refer to the already defined brush. At present, it is achieved by, <context id="ctx2" contextRef="#ctx1" brushRef="#brush1"/>. Then it will be changed to, <context id="ctx2" contextRef="#ctx1"> <brush brushRef="#brush1"/> </context>. Example 2: To define a new brush for the context. <context id="ctx2" contextRef="#ctx1"> <brush id="brush2"/> </context> ------------ Resolution: accepted ------------ Done. Normative clarifying language added. We continue to allow, e.g., both a brushRef and a brush child of context, but say which takes priority. ============ Comment #63: ------------ The <inkSource> block will often be specified by reference to a separate xml document, either local or at some remote URI. Ideally, <inkSource> blocks for common devices will become publicly available. Do you plan to setup a repository on the W3C's website (see 4.2.1 <inkSource> element)? ------------ Resolution: accepted ------------ The statement will be removed, because W3C (WG) do not have a plan to set up such a repository as of now. ============ Comment #64: ------------ The <sampleRate> element captures the rate at which ink samples are reported by the ink source. Many devices report at a uniform rate; other devices may skip duplicate points or report samples only when there is a change in direction. This is indicated using the uniform attribute, which must be designated "false" (non-uniform) if any pen-down points are skipped or if the sampling is irregular. uniform = xsd:boolean Sampling uniformity: Is the sample rate consistent, with no dropped points? Required: no, Default: unknown value = xsd:decimal The basic sample rate in samples/second. Required: yes So, when the ink source has an irregular sampling rate, the sampling rate "value" is still required BUT the "uniform" attribute has to be set to false? Isn't this contradictory? What is the purpose of giving a sample rate value when you know in advance that sampling is irregular? Also, when you write "<sampleRate value="200"/>" then the "uniform" attribute is by default set to "unknown", but it IS known to be uniform because a value is given. Comment: Greg, 12/20/06 As a consequence, I suggest dropping the "uniform" attribute and have a special sampleRate value in case the source is non uniform, something like negative (<= 0) value means unknown. In both cases, that is in the case of the actual specification or in the case of my new proposal, I am really wondering whether or not an InkML schema is capable of handling it (see 4.2.2 <sampleRate> element). Comment: Muthu, 04/11/07 The <inkSource> element is defined to have "zeroOrOne" <sampleRate> child element. So We should use <sampleRate> element only when there is a uniform sampling rate and skip it when the sampleRate is not uniform. So there is no specific attribute is required to indicate the uniform property. Ofcourse, It is easy to enforce this solution in Schema definition. ------------ Resolution: accepted ------------ Time channel should be used to get time information when Sampling Rate is non Uniform. When the Sampling Rate is Not Uniform, the value attribute of SampleRate element should be maximum sampling rate. The default value of the 'uniform' attribute should be true. ============ Comment #65: ------------ The <latency> element captures the basic device latency that applies to all channels, in milliseconds, from physical action to the API time stamp. This is specified at the device level, since all channels often are subject to a common processing and communications latency. Does this <latency> element come from the ancient times when the first specification draft was crafted up or is there any practical use of this element? And what if it's not the case? What if latency differs from one channel to another? If the knowing of the latency is of any importance, then you would end up having defined useless markup (see 4.2.3 <latency> element). As a consequence, why not bring latency information down to the <channelProperty> element (see 4.2.7 channelProperty element)? ------------ Resolution: rejected ------------ No Change. Note: Channel Property should appear as child to channel. It saves space, less overhead on the parser/interpreter in terms of associating property to the channel. ============ Comment #66: ------------ size = xsd:string The active area, described using an international paper size standard such as ISO216. Required: no, Default: unknown This is a good example of a typical drawback of InkML. You can refer to an international paper size standard such as ISO216 if it pleases you, however do not expect this information to be accurately used by any other application than yours. If there is nothing to enforce or to define the meaning of the attribute with precision, then why not drop it in favor of a custom <annotation> element? In the end, I think that such design choices break interoperability (see 4.2.4 <activeArea> element). ------------ Resolution: accepted ------------ Change in Spec: The active area, described using an international ISO paper sizes standard such as ISO216 Width and Height attributes should be made mandatory. Units attribute will be in one of the standard units. Note: Channel Property should appear as child to channel. It saves space, less overhead on the parser/interpreter in terms of associating property to the channel. ============ Comment #74: ------------ At most one of the attributes time, timestampRef or timeString may be given. The time thus given, plus the value of the attribute timeOffset, gives the time value of the timestamp. Again, can this be enforced by a schema (see 4.4.1 <timestamp> element contents)? Comment: Muthu, 04/11/07 We may consider the following change in the structure, 1. Remove the attributes time and timeString. Let the value given in the content with the type, <xs:union memberTypes="xsd:time xsd:dateTime"/>. So the content can be either of time or of type dateTime String. 2. Resolving Ambiguity: When both timeStampRef attribute and content or used, the content value gets precedence over the timeStampRef attribute. In other words, the timeStampRef attribute should be ignored. ------------ Resolution: accepted ------------ Specified priority order on time, timeString and timestampRef. ============ Comment #75: ------------ The default context may be explicitly specified using the URI "#DefaultContext". It is explicitly specified that using the URI "#DefaultContext" is legal, however it is not specified for "#DefaultCanvas" or "#DefaultTraceFormat" (see 4.5 The Default Context). ------------ Resolution: accepted ------------ the 2 missing URIs should be explicitly mentioned in the spec. Documentation has to be added for the same. ============ Comment #76: ------------ A <canvas> element must have an associated <traceFormat>, which may either be given as a child element or referred to by a traceFormatRef attribute. The coordinate space of the canvas is given by the regular channels of the trace format and any intermittent channels are ignored. When both are defined, which one prevails over the other? I would like it to be specified at this place of the document. ------------ Resolution: accepted ------------ Either of them could be specified. If both of them are specified, then child element overrides the attribute. ============ Comment #78: ------------ For certain classes of mappings, the inverse mapping may be determined automatically. These are mappings of type "identity", "affine" (for matrices of full rank), "lookup" (univariate, with linear interpolation), and "product" mappings of these. In this case, it is possible to specify that an inverse should be determined automatically by giving only the forward transform and specifying a value of true for the invertible attribute. When the inverse transform cannot be computed numerically, the inverse <mapping> has to be provided. In such a case, does the "invertible" attribute need to be set to "true" (see 5.2 element contents)? <canvasTransform> <mapping type="unknown"/> <mapping mappingRef="#map001"/> </canvasTransform> The example provided let the user think this is not the case. However, what if two <mappings> and "invertible = true" are specified? Comment: Muthu, 04/11/07. The following changes may be considered, Drop the attribute invertible. Always force to use two <mapping> child element to provide the forward and inverse transform. To indicate a mapping is invertible of another mapping: Introduce "invertibleRef" attribute which should be optional in mapping element. This attribute when used with href attribute to point to the mapping from which this mapping can be numerically invertible. Ambiguity: When both the mappingRef and Child elements to define the mapping are used, the child elements which define the mapping gets precedence and the mappingref attribute is ignored. ------------ Resolution: accepted ------------ If both mappings are provided, then ignore the 'invertible' attribute. Added this description 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. ============ Comment #89: ------------ Unknown Mapping Type InkML supports several types of mappings: unknown, identity, lookup table, affine, formula (specified using a subset of MathML) and cross product. The mapping type is indicated by the type attribute of a <mapping> element. What if something other than "unknown", "identity", "lookup", "affine", "mathml" or "product" is used? Should it be interpreted as "unknown" or as an application specific mapping type? In such a case, what about interoperability between applications (see 6.1 Mappings)? ------------ Resolution: rejected ------------ We believe that all types of mapping can be explained using the available type of mappings especially the MathML mapping type support wide variety of mapping definitions. So there will not be a case to provide application specific mapping definition. The application specific mapping type definition is not supported by InkML standard. As per the spec, it is useful in <canvasTransform> definition to give only inverse transform by setting the forward transform mapping type as "unknown". There is a proposal to drop the generic <mapping> element and create Specific element for each possible mapping type, it is discussed in Section 6.1.2: <bind> element Issue No: 1 which aims to solve the invalid combinations of attributes in the <bind> child element. ============ Comment #90: ------------ There are examples for the identity and mathml mappings, but not for lookup, affine and product ones (see 6.1 Mappings). ------------ Resolution: accepted ------------ 6.1.2 <bind> has an example of "lookup". Corrected example in 6.1.3 to be "product". Added a "affine" example in 6.1.4 for <matrix>. ============ Comment #91: ------------ source = xsd:string Specifies source data values and/or channel to be considered in the mapping. Required: no, Default: none target = xsd:string Specifies target data values and/or channel to be considered in the mapping. Required: no, Default: none column = xsd:string Specifies the assigned column within a lookup table either for source or target channels. Required: for lookup table bindings, Default: none variable = xsd:string Specifies the variable within a formula that represents the current source data/channel. Required: for mathml bindings, Default: none This truly offers pretty much room for invalid combinations (see 6.1.2 <bind> element attributes). Comment: Muthu, 04/11/07. We may consider the following change, Drop the <mapping> element and create different Mapping element for each possible mapping type with <bind> child element that have only the relevant attribute list. Example: For mapping type = lookup, We can create a <tableMapping> element as given below, <tableMapping id="mapping1"> <bind target="X" column="1"/> <table> </table> </tableMapping> All the Mapping element can have "href" attribute which play the role of mappingRef attribute in the <mapping>. Comment: Stephen will evaluate the above proposal. ------------ Resolution: accepted ------------ This is tracked by ISSUE-69 provided by Muthu. We update the column attribute data type to be integer, and explicity described the legal combinations of attributes. We also corrected errors in the MathML example (removed type="setvar"). ============ Comment #95: ------------ The definitions within a <definitions> block can be referenced by other elements using the appropriate syntax. Content within a <definitions> has no impact on the interpretation of traces, unless referenced from outside the <definitions>. In order to allow them to be referenced, elements within a <definitions> block must include an id; attribute. What happens when references are made to elements outside <definitions> blocks? ------------ Resolution: rejected ------------ Reference to elements defined outside <definitions> is allowed. The diffrence between the elements defined "inside" <definitions> and "outside" <definitions> is that the former does not represent ink data whereas the later lively represents ink data. The commmon thing about them is that both are available for reference by other elements. ============ Comment #97: ------------ Another use of <definitions> is to define digital ink traces for later reference. These may be given by <trace>, <traceGroup> or <traceView>, and may be referenced from other elements by the traceDataRef attribute. This is useful in archival applications. Same question, is it mandatory to put ink traces inside <definitions> elements when you want to reference them later on? ------------ Resolution: rejected ------------ It is not mandatory. ============ Comment #100: ------------ Interoperability issue because of <annotation> and <annotationXML> InkML provides generic ways of assigning metadata or semantics to ink via two elements <annotation> and <annotationXML>, modeled after the corresponding elements in MathML. However since annotations are typically application-specific, InkML does not attempt to prescribe the contents of these elements. Which is why InkML itself is unlikely to be useful as an exchange format, and lacks interoperability. ------------ Resolution: accepted ------------ It is natural that annotations are not interoperable. As a design principal, we want to support them as placeholder for the user defined information such as the recognition results and user defined brush properties etc. We can document this fact of them being harmful for interoperability in <annotation> and <annotationXML> elements sections. Added sentence to 6.3 Annotations: "Since the contents of <annotation> or <annotationXML> elements are application defined, implementors should use them with care and remain aware that other implemnetaions may ignore them or fail to round-trip unrecognized annotations." ============ Comment #101: ------------ Semantic tagging of traces The <annotation> element provides a mechanism for inserting simple textual descriptions in the ink markup. This may be use for multiple purposes. For instance, the text contained in the <annotation> may include additional information provided by the user generating InkML, and may be displayed by an InkML consumer rendering a graphical representation of traces. Or it may be used for the indication of metadata such as the writer, the writing instrument. Another important potential application is the semantic tagging of traces. Semantic tagging of traces is important. Maybe InkML should address it more thoroughly (see 6.3 <annotation> element). ------------ Resolution: accepted ------------ The explanations given as part of the resolution of the above issue (Section 6.3, #100) will address this. ============ Comment #102: ------------ Suggestions on Semantic tagging of traces For semantic tagging, one of the common types of <annotation> is "contentCategory", which describes at a basic level the category of content that the traces represent; e.g., "Text/English", "Drawing", "Math", "Music". Such categories are useful for general data identification purposes, and may be essential for selecting data to train handwriting recognizers in different problem domains. Although largely application-defined, a number of likely, common categories are suggested below. 1. Text/<language>[/<script>][/<sub-category>] (e.g., Text/jpn/Kanji, Text/en/SSN) 1. Drawing[/<sub-category>] (e.g., Drawing/Sketch, Drawing/Diagram) 1. Math 1. Music 1. Chemistry[<sub-category>] The language specification may be made using any of the language identifiers specified in ISO 639, using 2-letter codes, 3-letter codes, or country names. Some text may also require a script specification (such as Kanji, Katakana, or Hiragana) in addition to the language. For some applications it may be useful to provide additional sub-categories defining the type of the data. For example, some suggested sub-categories for Text include: 1. SSN (Social Security Number) 1. Phone 1. Date 1. Time 1. Currency 1. URL Suggested possible sub-categories for Drawing are: 1. Sketch (Not suitable for geometric clean-up) 1. Diagram (Suitable for geometric clean-up) InkML suggests ways of tagging ink traces. Unfortunately, those are only suggestions. Handwriting recognition is a primary treatment performed on handwritten digital data, and annotation suggestions are not enough to enable handwriting recognition aware applications to interoperate with each other. ------------ Resolution: rejected ------------ The comment is interesting and complex. As the <annotation> element is left for application dependent definitions, an elaborate description of 'contentCategory' as part of the standards specification is not favored. ============ Comment #104: ------------ This element allows ink to be annotated with general XML objects. These may be given either as the content of this element or may be referred to by a href attribute, but not both. Again, practical to use, but may be difficult to enforce. ------------ Resolution: accepted ------------ The issue is addressed by the resolution of the issue #143 in the section, "Spec-wide". The name of the self-referencing attribute 'href' is being under review; we are thinking of giving a more suitable name for it which is also addressed in "Spec-wide", issue #143. 1. Support 'href' attribute that can refer to another element of the same type in all appropriate elements. Example: context, all the children of context, mapping and annotationXML. 2. When a element have 'href' attribute and children then, the data in children overrides the data inherited from the referred element. It is applicable for leaf elements such as 'brush'. Interpretation of the data when both 'href' and child elements are used : The value of the element is inherited from the element value through 'href' attribute and the child element definition would override the inherited value to get the final value for the child element of the element. This behavior is commonly known as "inheritance". ============ Comment #105: ------------ Suggestion on parser implementation for Units Even units require a dedicated parser, although it should not be that difficult to write one with the help of regular expressions. ------------ Resolution: accepted ------------ The channels have now been defined with default units. We defined default value for all units. For example the default value for 'length' units is 'mm'. ============ Comment #106: ------------ A trace or traceGroup can both reference a context and override its brush, as in the following: <trace xml:id="t001" contextRef="#context1" brushRef="#penA">...</trace> <traceGroup contextRef="#context1" brushRef="#penA"> <trace xml:id="t002">...</trace> </traceGroup> which assigns the context specified by "context1" to traces "t001" and "t002", but with "penA" instead of the default brush. Somehow, this behavior should be explicitly specified instead of being introduced at the end of the document, in a section giving usage examples. ------------ Resolution: accepted ------------ We need to more clearly identify how context information is combined. Explicility spelled out the order of precdence of contextRef versus brushRef, and the nesting of traceGroups and traces. ============ Comment #107: ------------ Brushes, traceFormats, and contexts which appear outside of a <definitions> block and contain an id attribute both set the current context and define contextual elements which can be reused It seems to answer my previous questions about references to elements that are not packed in to <definitions> blocks in the same document. Does it apply to elements defined in other documents ? I guess the answer is yes by nature of URIs. Comment: Muthu, 04/02/07 But as per the spec, <brush> element can be defined only within <context> other than within <definitions> block. So in order to define a new brush, we have to create a <context> element with the new <brush> element definition??. ------------ Resolution: accepted ------------ Added language to section 7 to clarify that streaming and archival. ============ Comment #108: ------------ A <context> element can also override values of a previously defined context by including both a contextRef attribute and one or more of the canvasRef, canvasTransformRef, traceFormatRef or brushRef attributes. The following: <context contextRef="#context1" brushRef="#penB"/> Also answers my previous questions. Somehow, I guess it would be a good idea to specify these behaviors in the corresponding sections rather in the streaming application mode usage example. ------------ Resolution: accepted ------------ Added language to section 7 to clarify that streaming and archival. ============ Comment #109: ------------ Generally speaking, the markup contains various useless <span> elements. ------------ Resolution: accepted ------------ Cleaned up the empty <span>'s ============ 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. ============ Comment #111: ------------ This fourth version of the Working Draft includes a few conceptual changes to simplify the definition while achieving greater expressive power. It also contains many small changes of details to make element and attribute use uniform accross the the definition to make it easier to learn and simpler to process. Should be "across the" (see Status of this document). ------------ Resolution: accepted ------------ Fixed "accross" to "across". ============ Comment #112: ------------ Canvas transformations allow ink from different devices to combined and manipulated by multiple parties. "be" is missing: "Canvas transformations allow ink from different devices to be combined and manipulated by multiple parties" (see 1.2 Elements). ------------ Resolution: accepted ------------ Added missing "be" to sentence. ============ Comment #113: ------------ Certain applications, such as collaborative whiteboards (where ink coming from different devices is drawn on a common canvas) or document review (where ink annotation from various sources is combined), will require ink sharing. I would have used a plural form: where ink annotations from various sources are combined (see 1.2 Elements). ------------ Resolution: accepted ------------ Changed "(where ink annotation from various sources is combined)" to "(where ink annotation from various sources are combined)". ============ Comment #114: ------------ For ease of implementation, it is recommended that, in archival mode, referenced elements be defined inside a declaration block using the <definitions> element. Not always recognized by non native English speakers. Maybe "For ease of implementation in archival mode, referenced elements should be defined inside a declaration block using the <definitions> element." would be easier to understand. Not a big issue anyway (see 1.3 Exchange Modes). ------------ Resolution: accepted ------------ Rephrased per recommendation in comment ============ Comment #115: ------------ "Traces are the basic element used to record the trajectory of a pen as a user writes digital ink." I would have written: "<trace> is the basic element used to record the trajectory of a pen as the user writes digital ink." (see 3 Traces and Trace Formatting). ------------ Resolution: accepted ------------ Rephrased per recommendation in comment ============ Comment #116: ------------ Traces generated by different devices, or used in differing applications, may contain different types of information. InkML defines channels to describe the data that may be encoded in a trace. I guess a link is welcome here (see 3 Traces and Trace Formatting). ------------ Resolution: accepted ------------ Added a link to Channel ============ Comment #117: ------------ The <intermittentChannels> lists those channels whose value may optionally be recorded for each sample point. I would have written: "The <intermittentChannels> element lists those channels whose value may optionally be recorded for each sample point." (see 3.1.2 <intermittentChannels> element) ------------ Resolution: accepted ------------ Changed to "The <intermittentChannels> element lists those channels whose value may optionally be recorded for each sample point." ============ Comment #118: ------------ units = xsd:string The units in which the values of the channel are xpressed (numerical channels only). Required: no, Default: none Should be "expressed" (see 3.1.3 <channel> element). ------------ Resolution: accepted ------------ Changed "xpressed" to "expressed". ============ Comment #119: ------------ The <mapping> element can be employed to specify an applied sine transformation. I would have linked the <mapping> element with the corresponding section (see 3.1.4 Orientation Channels). ------------ Resolution: accepted ------------ Added link to <mapping> ============ Comment #120: ------------ <channel name="T" type="integer" units="ms" respectTo="#ts1"/> Fix indentation (see 3.1.7 Time Channel). ------------ Resolution: accepted ------------ Fixed the indentation in the <channel name="T"> example. ============ Comment #121: ------------ 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). I would have linked the <inkSource> element with the corresponding section (see 3.1.7 Time Channel). ------------ Resolution: accepted ------------ Added link to <inkSource> ============ Comment #122: ------------ The appearance of a <traceFormat> element in an ink markup file ... I would have used "in an InkML file" (see 3.1.9 Specifying Trace Formats). ------------ Resolution: accepted ------------ Changed "ink markup file" to "InkML file" ============ Comment #123: ------------ Additionally, wsp may occur anywhere except within a decimal or hex and must occur if required to separate two valuess. Should be "values" (see 3.2.1 <trace> element contents). ------------ Resolution: accepted ------------ Changed "valuess" to "values" ============ Comment #124: ------------ All traces must begin with an explicit value, not with a first or second difference. This is true of continuation traces as well. This allows the location and velocity state information to be discarded at the end of each trace, simplifying parser design. I suggest: "This is true for continuation traces" (see 3.2.1 <trace> element contents). ------------ Resolution: accepted ------------ Added "This is true for continuation traces" ============ Comment #125: ------------ There is a 3.2.1 <trace> element section but no 3.2.2 section. ------------ Resolution: accepted ------------ Added section number ============ Comment #126: ------------ [ http://www.w3.org/TR/2006/WD-InkML-20061023/#traceAggregate 3.3 Trace Collections section]'s id is "#traceAggregate", change to "#traceCollections". ------------ Resolution: accepted ------------ Changed "#traceAggregate" to "#traceCollections" ============ Comment #127: ------------ Although the use of the <context> element and attributes is strongly encouraged, default interpretations are provided so that they are not required in an ink markup file if all trace data is recorded in the same virtual coordinate system, and its relationship to digitizer coordinates is either not needed or unknown. "ink markup file" or "InkML" file ? Maybe it's a good idea to chose one and stick to it (see 4.1 The <context> element) ? ------------ Resolution: accepted ------------ Changed "ink markup file" to "InkML file" ============ Comment #128: ------------ The <inkSource> element will allow specification of: 1. Manufacturer, model and serial number (of a hardware device) 1. Text description of source, and reference (URI) to detailed or additional information 1. Trace format - regular and intermitent channels reported by source 1. Sampling rate, latency and active area 1. Additional properties of the device in the form of name-value-units triples 1. Properties of individual channels Should be "intermittent" (see 4.2.1 <inkSource> element). ------------ Resolution: accepted ------------ Changed "intermitent" to "intermittent" ============ Comment #129: ------------ For the sake of consistency, the <srcProperty> element could have been named <sourceProperty>. In fact, it is the only markup that has an abbreviated name (seen 4.2.5 <srcProperty> element). ------------ Resolution: accepted ------------ The <srcProperty> element will be renamed to <sourceProperty> ============ Comment #130: ------------ The <channelProperties> element is meant for describing properties of specific channels reported by the ink source. Properties such as range and resolution may be specified using corresponding elements. For more esoteric properties (from a lay user's standpoint) the generic channelProperty element may be used. I would replace "channelProperty" by "[ http://www.w3.org/TR/2006/WD-InkML-20061023/# channelProperty <channelProperty]>" (along with the link) (see 4.2.6 channelProperties element ). ------------ Resolution: accepted ------------ Changed "channelProperty" to <channelProperty> with a link to channelPropertyElement. ============ Comment #131: ------------ I would replace name = xsd:string Name of property of device or ink source. Required: yes by name = xsd:string The name of the property of device or ink source. Required: yes (see 4.2.7 channelProperty element attributes) ------------ Resolution: accepted ------------ Rephrase per recommendation in comment ============ Comment #132: ------------ There is a 4.3.1 <brush> element section but no 4.3.2 section. ------------ Resolution: accepted ------------ Added section number ============ Comment #133: ------------ There is a 4.4.1 <timestamp> element section but no 4.3.2 section. ------------ Resolution: accepted ------------ Added section number ============ Comment #134: ------------ If the canvas tranform is given as an affine map of full rank, then it may be inverted numerically Should be "transform" (see 5 Canvases). ------------ Resolution: accepted ------------ Changed "tranform" to "transform" ============ Comment #135: ------------ If the type attribute has value mathml then the content is a subset of MathML restricted to the following subset of Content MathML 2.0 elements defining arithmetic on integers, real numbers and boolean values: . Numbers: cn . Named constants: exponentiale, pi, true, false . Identifiers: ci. These must be associated to channels using a <bind> element. . Arithmetic: plus, minus, times, divide, quotient, rem, power, root, min, max, abs, floor, cieling . Elementary classical functions: sin, cos, tan, arcsin, arccos, arctan, exp, ln, log . Logic: and, or, xor, not . Relations: eq, neq, gt, lt, geq, leq . Operator application: apply Are these ones correct ? Shouldn't it be exponential and ceiling? (see 6.1.1 <mapping> element) ------------ Resolution: accepted ------------ Changed "exponentiale" to "exponential, e" and changed "cieling" to "ceiling". ============ Comment #136: ------------ The definitions within a <definitions> block can be referenced by other elements using the appropriate syntax. Content within a <definitions> has no impact on the interpretation of traces, unless referenced from outside the <definitions>. In order to allow them to be referenced, elements within a <definitions> block must include an id; attribute. Maybe it should be: "Content within a <definitions> block has no impact on the interpretation of traces, unless referenced from outside the <definitions> block". Also, is the semicolon required? (see 6.2.1 definitions element) ------------ Resolution: accepted ------------ Rephrase per recommendation in comment ============ Comment #137: ------------ The <annotation> element provides a mechanism for inserting simple textual descriptions in the ink markup. This may be use for multiple purposes. Should be "This may be used for multiple purposes". ------------ Resolution: accepted ------------ Changed "use" to "used". ============ Comment #138: ------------ [ http://www.w3.org/TR/2006/WD-InkML-20061023/#streamsAndArchives 7 Streams and Archives] rename to "7 Archives and Streams" to match the content of 7.1 and 7.2 sections. ------------ Resolution: accepted ------------ Rephrase per recommendation in comment. Comment: Muthu, 03/30/07 On doing this, we have to modify the second paragraph in section 7 where there is a reference to 'former' and 'later' that refer to Streams and Archives. ============ Comment #139: ------------ Replace all "refered" occurrences by "referred", found several times. ------------ Resolution: accepted ------------ Changed all "refered" to "referred". ============ Comment #143: ------------ Streaming how-to I started having a look at the last draft of the InkML specification. Before I send any feedback, I would like to know more about streaming mode since I'm not familiar at all with XML streaming: - how is it done in practice ? - does StAX need to be used or rather something like SOAP ? - when you send continuation <trace> elements, do they have to be wrapped inside <ink></ink> markups ? ------------ Resolution: accepted ------------ Added language to section 7 to clarify that streaming and archival. Added comment to implementation guidelines saying that any of the usual XML protocols (StAX, SOAP, etc) may be used to transmit InkML documents or fragments between subprograms or distributed programs.
Received on Monday, 11 October 2010 01:00:29 UTC