[mpeg-OTspec] Draft ballot comments for 3rd edition OFF text

[Cameron McCormack]

On 02/06/14 23:56, Levantovsky, Vladimir wrote:
> Thank you for reminding me about your comment, I marked it to follow up with you but never did.
>
> Regarding the changes you suggest earlier, I have a couple of questions:
>
> 1) Right now, the SVG Integration document is listed in the Bibliography section and is meant to be informative. We do reference it when describing the secure animation mode, however, the normative requirements for scripts, external references, etc. are explicitly defined in the text of the OFF. For the changes you suggested (i.e. remove UA style sheet definitions in OFF and reference them from SVG Integration document) - the document would have to be made normative. Do you know when the document is going to be finalized?  It would be good to have it moved to at least Last Call status before the OFF text is published (which is expected to happen in April - July 2015).
>
> 2) Alternatively, we could do something similar to how secure animation mode is described - normative UA style sheet requirements can be described verbally in the OFF text, with the reference to exact UA style sheet definitions in the SVG Integration. If this is acceptable, please suggest the exact language you want to see in the spec.
>
> My personal preference would be to do the latter and not be dependent on the progression of the SVG Integration document while still be able to reference it.

I think the main reason we want to have the requirements in the SVG 
Integration document is so that we can update it as new SVG features 
come about without having to make a new version of the OFF spec.  That 
would mean that if we do have any descriptions of the requirements in 
the OFF spec, that they are basically an informative summary of the 
"real" requirements that exist in SVG Integration at the time OFF is 
published, but subsequent updates to SVG Integration would override 
those summaries.

If the normative requirements remain in the OFF spec and they are all 
that is required to implement it, then there's no reason for SVG 
Integration to be referenced at all.

I think this means (1) is what we should do.  Doing (2) and allowing SVG 
Integration to be updated as new SVG language features are developed and 
expecting OFF implementers to follower the SVG Integration updates 
sounds like making the reference informative just to satisfy process 
requirements with the understanding that implementers really treat it as 
a normative reference.  I'd rather be clearer about what is normative.

April 2015 is a deadline we in the SVG Working Group can work towards.