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

Hi Charles,

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:13 PM
To: 'Charles Pritchard'
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-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, 11 October 2010 00:59:53 UTC