[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-30 are here: http://lists.w3.org/Archives/Public/www-multimodal/2010Jun/0004.html

Thank you for your input!

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

============
Comment #199:
------------
I'm currently working on an SVG+InkML profile, and having reasonable
success.

Something came up for me:
InkML does suggest that brush properties be left to the implementation:
http://www.w3.org/TR/InkML/#brushElement
"Brushes may be used to convey information... all that matters is that
brushes are distinct so no brush properties are necessary"

It also provides a mechanism to pass metadata about brushes, through the
brushProperty element:
http://www.w3.org/TR/InkML/#brushPropertyElement

brushProperty works quite well in archived mode, for brush metadata.

However, it doesn't seem that it's been examined for Streaming mode.
Within a stream, we want to minimize the number of defined brushes, and will
likely build-upon a brush, changing its color, size, etc.

While the channels definition allows for some measure of this kind of
activity,
it has nothing to offer when it comes to brush property meta data.
.....

It seems to me that a stream should be able to re-use and replace the
definitions
construct. This allows inheritance of existing values across boundaries,
and setting
boundaries for garbage collection of obsolete element information.

The following example is intended for streaming mode.

It sets up a brush called "mybrush", with three brushProperty elements.
Later on in the stream, it re-uses that brush, with its brushProperty
elements,
but alters a few of them, changing the value of the first element and
emptying
the value of the third.

By using <definitions> to clear the defined state stack, we're able to allow
streaming implementations to process an unlimited amount of data without
requiring they keep prior definitions in memory; and we allow them to
reference the prior definition set through inheritance.



Example:

<definitions>
<brush xml:id="mybrush">
<brushProperty name="key1" value="val1" />
<brushProperty name="key2" value="val2" />
<brushProperty name="key2" value="val3" />
</brush>
</definitions>
<context brushRef="#mybrush">
<trace> ..... </trace>
<definitions>
<brush xml:id="mybrush" brushRef="#mybrush">
<brushProperty name="key1" value="newValue" />
<brushProperty name="key3" value="" />
</brush>
</definitions>
<context brushRef="#mybrush">
<trace> ..... </trace>
------------
Resolution: rejected
------------
Having a second <brush> element with the same xml:id in the stream would be invalid XML according to the XSD schema.  The xml:id attribute is of XML Data type 'ID', which means only a single instance of <brush xml:id="foo"/> may exist in the stream.

You could still accomplish what you want to do by having a sequence of ids: <brush xml:id="foo"/> .... <brush xml:id="foo2" brushRef="#foo"/> .... <brush xml:id="foo3" brushRef="#foo2"/>, etc.   Yes, it's not efficient for the implementations' storage, but we can't allow streams that are invalid to the XML ID/IDREF rules, and changing the schema to not use ID/IDREF is not feasible at this time.

Received on Monday, 30 August 2010 06:31:29 UTC