- From: Craig Northway <craign@cisra.canon.com.au>
- Date: Thu, 02 Jun 2005 13:19:01 +1000
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: Antoine Quint <ml@graougraou.com>, www-svg@w3.org, WG SVG <w3c-svg-wg@w3.org>
Boris,
I fixed your comment on the extraneous 'then' in the definition of
"viewport coordinate system". I removed the offending word.
Regarding your comment on the current SVG document fragment. The reason
that some definitions extend to cases not covered in the Tiny profile is
that this will save needlessly repeating information in SVG Full 1.2.
Where possible the editors have tried to make definitions and generic
concepts broad enough to cover both profiles.
For this case I propose to clarify the SVG 1.2 Tiny specification by
modifying the definition of SVG document fragment and current SVG
document fragment:
current SVG document fragment
The XML document sub-tree which starts with the ancestor 'svg'
<mailbox:///M%7C/Home/pop/Drafts?number=13098261&part=1.2&filename=struct.html>
element of a given SVG element, with the requirement that all
container elements between the 'svg'
<mailbox:///M%7C/Home/pop/Drafts?number=13098261&part=1.2&filename=struct.html>
and this element are all elements in the SVG language and namespace.
SVG document fragment
The XML document sub-tree which starts with an 'svg'
<mailbox:///M%7C/Home/pop/Drafts?number=13098261&part=1.2&filename=struct.html>
element. An SVG document fragment can consist of a stand-alone SVG
document, or a fragment of a parent XML document enclosed by an
'svg'
<mailbox:///M%7C/Home/pop/Drafts?number=13098261&part=1.2&filename=struct.html>
element. In SVG Tiny 1.2 the SVG document fragment cannot contain
nested 'svg'
<mailbox:///M%7C/Home/pop/Drafts?number=13098261&part=1.2&filename=struct.html>
elements.
If you and the working group are happy with this I'll make the changes.
Regards,
Craig
Boris Zbarsky wrote:
>
> Antoine Quint wrote:
>
>> What I meant to say is that the <svg> element is only allowed as the
>> root-most element of an SVG fragment. Section 5.1.1 [0]
>
>
> OK, but then my question about section 1.6 stands -- why give a
> definition that has various clauses to handle cases that the spec
> defines as never happening? There are also other references to the
> "outermost <svg> element", which all make it sounds like non-outermost
> ones are allowed...
>
> -Boris
>
>
Received on Thursday, 2 June 2005 03:19:04 UTC