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

  I certainly agree that XML ID rules should be kept. Working with a 
sequence of IDs is reasonable, it's efficient with gzip. My proposal for 
re-using IDs is unnecessary and complex.

If there's time and space, I'd like to put forward another proposal to 
address the issue:

With a data-heavy or long-running stream, data should be be disposed of 
by the implementation, as it works to "progressively render on the 
client or clients." ( B.1 Implementation Guidelines ) This requires that 
implementations dump unneeded data: the intent is to preserve RAM.

It seems like InkML is breaking new ground with 7.2 Streaming 
Applications. Are there existing precedents for streaming XML ID/IDREF 
rule-based content?
Is there an example of streaming <brushProperty> ? The streaming 
examples in 7.2 and 7.3 do not have an example usage for <brushProperty>.
I'd like to see <brushProperty> used anonymously, in a stream. 
Currently, it may only be used within a brush.

Streams provide "an event-driven model of ink generation": without 
markers for garbage collection, global brushProperty values must be kept 
in memory and/or storage.

I've two proposals, for 7.2 to try to address the issue:

brushProperty MAY be used in streamed mode outside of the <brush> 
property. <brushProperty> MAY be disposed of by the implementation, once 
it can not longer be referenced.

Example:
<context brushRef="#penA"/>
<brushProperty name="generic" value="generic" />
<context brushRef= ""/>
<brushProperty name="generic" value="generic" />


Streamed content MUST NOT contain context references to items, that have 
not been referenced or set recently in the stream, unless those XML IDs 
were created within a <definition> tag.

Example:
<definition><brush xml:id="penA" /></definition>
<brush xml:id="penC" />
<context brushRef= "penA"/>
...
<context brushRef= "penC"/>
... [a lot of data] ...
<context brushRef= "penA"/><!-- valid -->
<context brushRef= "penC"/><!-- invalid -->


These two proposals allow implementations to drop stale data, and keep 
brush definitions to a minimum.
They allow an anonymous brush property bundle, as in example one, and 
garbage collection of out-dated data, as in example two.

There is a conflict with Archive InkML in this proposal. The following 
can not be serialized in Archive InkML:
<context brushRef="" />
<brushProperty name="generic" value="generic" />

<brush xml:id=""/> is not valid.
<brushProperty> must be allowed outside of a <brush> tag in Archive 
InkML to allow Streamed InkML: <context brushRef="" /><brushProperty />

-Charles

On 10/10/2010 5:59 PM, Tom Underhill wrote:
> 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.
>