Re: ISSUE-2147 (external-refs confusing): Section on externally referenced documents confusing [Last Call: SVG 1.2 Tiny]

Hi Cameron,

Thank you for your editing. This is indeed a lot better than before. I just have two comments. See below.

Cameron McCormack a écrit :
> Hello all.
> 
> Cameron McCormack:
>>>   Each primary document maintains a dictionary that maps IRIs to
>>>   resource documents.  This dictionary is used whenever a resource
>>>   document is to be loaded because the primary document or one of its
>>>   resource documents references it.  Before loading a resource document,
>>>   its IRI is first looked up in the primary document’s dictionary to
>>>   determine if it has already been loaded.  If so, then that
>>>   already-loaded document is used instead of creating a separate
>>>   document instance.  Thus, for each primary document, a given resource
>>>   document is loaded only once.  Primary documents, however, are always
>>>   separate, self-contained document instances, and resource documents
>>>   are not shared between primary documents.
> 
> Erik Dahlström:
>> I disagree with this, and I think similar wording is also in the
>> other proposal and in the spec currently. Specifically I'd like the
>> spec to avoid requiring reloading of the same resource if the primary
>> documents are in the same document (the inline in XHTML case).
>>
>> One solution could be to remove the mention of the document fragment
>> case and to fix that in a later spec. Another would be to say that a
>> primary document is the document itself, and this would also work for
>> the other cases since they would all establish a new document. Yet
>> another would be to add a sentence saying that resource documents may
>> be shared among primary documents if the primary documents are inline
>> in the same document.
> 
> After discussion in the working group, we agreed with Erik’s suggestion
> to have resource documents shared between SVG document fragments within
> the one document (although note that each SVG document fragment within
> the one non-SVG document still has its own timeline).
> 
>>> And a question: should resource documents be restricted to being entire
>>> SVG documents, or can they be SVG document fragments within say an XHTML
>>> document?
>> Any document capable of providing the necessary svg elements (in
>> the proper namespace) should be allowed as the container IMHO. This
>> wouldn't rule out HTML5 documents, if the elements were put in the DOM
>> correctly.
> 
> This was agreed to also.
> 
> Here is my proposed rewording, incorporating these two changes, which
> has also been committed to the spec:
> 
>   14.1.6 Processing of external references to documents
>   
>   When an SVG user agent resolves an external reference to a document,
>   how the document is loaded and processed depends on how the document
>   was referenced. As defined below, a document is classified as either
>   a primary document or a resource document, and this classification
>   determines the document's processing with respect to loading of
>   external references.
>   
>   A primary document is one that is to be presented in whole by the user
>   agent. Specifically, the following are classified as primary
>   documents:
> 
>    * An entire document, be it an SVG stand-alone document or some other
>      document that can contain SVG document fragments, that is loaded
>      into a user agent for presentation, such as when navigating a web
>      browser to an IRI, whether by typing the IRI into the browser's
>      address bar, clicking on a link to that IRI, or having the
>      Location::assign() method invoked. (In an HTML 5 user agent, this
>      is when a document is part of a top-level browsing context
>      ([HTML5], section 4.1.1).)
> 
>    * An entire SVG document that is loaded due to it being referenced by
>      an 'animation' element.
> 
>    * A document that is loaded due to it being referenced for inclusion
>      by a parent non-SVG document for presentation, such as using the
>      HTML 'object' or 'iframe' elements.
>   
>   A resource document is a document that has been loaded because it is
>   referenced as a resource by an SVG document fragment. 
It should say here "because parts of it are referenced as resources" as opposed to "presented in whole" in the above definition. Similar wording would be good as well.


> Specifically,
>   the following kinds of external references, all of which are
>   references to elements, will cause the loaded document to be
>   classified as a resource document:
>   
>     * The 'xlink:href' attribute on a 'use' element.
>     * The 'xlink:href' attribute on a 'font-face-uri' element.
>     * A paint server reference in a 'fill' or 'stroke' property.
>   
>   Note that neither a primary document nor a resource document need be
>   a complete SVG document (with the rootmost 'svg' element being the
>   document element). Both may be non-SVG documents that contain SVG
>   document fragments.
>   
>   Each primary document maintains a dictionary that maps IRIs to
>   resource documents. This dictionary is used whenever a resource
>   document is to be loaded because an SVG document fragment within
>   the primary document (or one of its resource documents) references
>   it. Before loading a resource document, its IRI is first looked up
>   in the primary document's dictionary to determine if it has already
>   been loaded. If so, then that already-loaded document is used instead
>   of creating a separate document instance. Thus, for each primary
>   document, a given resource document is loaded only once. Primary
>   documents, however, are always separate, self-contained document
>   instances, and resource documents are not shared between different
>   primary documents.
>   
>   The IRI used as the key in the dictionary of resource documents
>   must be the absolute IRI after resolving it against any applicable
>   base IRI, and comparisons of the dictionary keys must be performed
>   using a Simple String Comparison, as defined in section 5.3.1 of
>   Internationalized Resource Identifiers [RFC3987].
>   
>   Whether a document is a primary document or a resource document, its
>   processing once loaded is the same: each SVG document fragment within
>   the document acts as a separate SVG processing context in which events
>   are fired, scripts are executed, an animation timeline is created
>   and animations are run, stylesheets are applied (if supported by the
>   SVG user agent), and so on. Since a resource document is not just a
>   static DOM, any changes to it (be they modifications by script or
>   changing presentation values with animation) will be visible through
>   all references to that resource document.
>   
>   Note that since IRI references to resources from different primary
>   documents will result in logically separate resource documents being
>   instantiated, an SVG user agent will in general not be able to
>   conserve memory by having only one instance of the resource document
>   in memory. In the case that many primary documents all have references
>   to a single, large, common resource file, this will likely result in
>   a large amount of memory consumed. If the SVG user agent is able to
>   prove that the primary documents will behave exactly the same if a
>   single instance is shared in memory (by using copy-on-write semantics
>   for the resource documents, for example), then such an optimization
>   may of course be performed.
>   
>   References to any other kinds of document, such as media or external
>   scripts, are not classified as primary or resource documents. Multiple
>   references to media at a particular IRI always result in separate
>   timelines being created.
This last part is also fine but you have a sentence explaining the behavior for media. You should explicitely say what happens for script. It may use a reference to HTML if you think it's better.

Regards,


Cyril

>    — http://dev.w3.org/SVG/profiles/1.2T/publish/linking.html#externalReferences
> 
> Cyril, could you please indicate as soon as possible whether you are
> satisfied with this resolution.
> 
> Thanks,
> 
> Cameron
> (ACTION-2345)
> 


-- 
Cyril Concolato
Maître de Conférences/Associate Professor
Groupe Mutimedia/Multimedia Group
Département Traitement du Signal et Images
/Dept. Signal and Image Processing
Ecole Nationale Supérieure des Télécommunications
46 rue Barrault
75 013 Paris, France
http://tsi.enst.fr/~concolat

Received on Friday, 31 October 2008 08:29:29 UTC