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

  Looks good.

Checking on my understanding of the new anonymous brush context:

Is the behavior of <brush /> to add properties to the existing brush 
context and <brush brushRef="" /> to reset the context to its default state?
Or is <brush brushRef="" /> equivalent to <brush /> ?

Example:

<brush brushRef="#penA"/>
<trace xml:id="t001">...</trace>
<brush brushRef="#penA">
<brushProperty name="color" value="#FF0000"/>
</brush>
<trace xml:id="t002">...</trace>
<brush>
<brushProperty name="generic" value="generic"/>
</brush>
<trace xml:id="t003">...</trace>
<brush brushRef="" />
<trace xml:id="t004">...</trace>

"t001" renders using penA.
"t002" renders using penA with color red.
"t003" renders using penA with color red and a generic brush property. ?
"t004" renders using the default brush.

-Charles

On 10/11/2010 10:34 AM, Tom Underhill wrote:
>
> Thanks Charles.   I reviewed your proposal, the working draft, and 
> then this morning we discussed the issue during the ink conference 
> call.   I believe we have a resolution that we will all find satisfactory:
>
> In section 7.2, "Streaming Application", the spec already says:
>
> The appearance of a |<brush>| element in the ink markup sets the 
> current brush attributes, leaving all other contextual values the 
> same. Likewise, the appearance of a |<traceFormat>| element sets the 
> current traceFormat, and the appearance of a |<context>| element sets 
> the current context.
>
> As this would imply, and the examples later illustrate, an anonymous 
> <context> may appear within the stream that overrides all or parts of 
> the current context.   Although there are no examples showing this, 
> this statement says that anonymous <traceFormat> or <brush> elements 
> may also appear within the stream and would also override those parts 
> of the current context (override the traceFormat of the context if an 
> anonymous <traceFormat> appeared, or override the brush of the context 
> if an anonymous <brush> appeared).
>
> The sections for traceFormat (3.1.1) and context (4.1) already support 
> anonymity for streaming because their xml:id attributes are already 
> optional.   The section for brush (4.3.1) does not support anonymity 
> because its xml:id attribute is required.   We believe that is an 
> oversight on our part and will change it from required to optional in 
> both section 4.3.1 of the spec and in the XML Schema.
>
> I will also update the examples to show samples of streaming XML 
> overriding brushes.  For instance:
>
> <brush brushRef="#penA"/>
>
> <trace xml:id="t001">...</trace>
>
> <brush brushRef="#penA">
>
> <brushProperty name="color" value="#FF0000"/>
>
> </brush>
>
> <trace xml:id="t002">...</trace>
>
> In the example above trace "t001" would be render using the attributes 
> of brush "penA".   Then the current brush is modified to a copy of 
> "penA" with its color attribute changed to red.   Trace "t002" is then 
> rendered using the new current brush which is red.
>
> A streaming application must still store maps of any explicitly named 
> brushes, traceFormats, and contexts.   But it would only have to store 
> a single "current" context which contains a "current" brush and a 
> "current" traceFormat.   As anonymous brushes, traceFormats, and 
> contexts are encountered in the stream, the implementation writes over 
> the fields within its "current" objects.
>
> Thanks,
>
> Tom
>
> *From:* Charles Pritchard [mailto:chuck@jumis.com]
> *Sent:* Sunday, October 10, 2010 7:55 PM
> *To:* Tom Underhill
> *Cc:* www-multimodal@w3.org; smwatt@gmail.com
> *Subject:* 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  <mailto:www-multimodal@w3.org>';'smwatt@gmail.com  <mailto: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.
>   
>