[1.2T-LC] Comments and suggestions, mainly regarding the Linking section

Sorry for the delayed answer to the comments Last Call - maybe these
can still be reviewed under the official LC limit (October 13th)
[GENERAL]. ;-D I've quickly checked that these items were not yet
included in the latest version [LATEST] in order to avoid noise as
much as possible. ;-) I have the notion that these comments and
corrections are, overall, tiny things, but I've tried to gather as
many details as possible: I strongly believe that high quality
standards differ from good standards in the amount of attention given
to detail - I hope the SVG-WG will appreciate! :-)



1. Usage of "formerly" in Author list [AUTHORS].

(Sorry for explicitly referring to Doug Schepers but he was the author
that made me realize this small incoherence.) For example, "Doug
Schepers, W3C (formerly Vectoreal)". Does this mean that W3C was
previously named Vectoreal or that Doug Shepers, currently working at
W3C, has previously worked at Vectoreal? (This is just for
illustration purposes, I'm convinced that I know the answer.) I'd
suggest using "formerly of" (already found for some of the authors)
where applicable.



2. Typo in Linking section [LINKING]

In subsection "14.1.4 Reference restrictions", "not" is repeated.

Current wording:

A: A reference to a fragment within the current document (e.g.
'#someelement'). If the referenced fragment is not within the current
SVG document fragment then whether the reference is an invalid IRI
reference or not not is defined by the host language.

Proposed change:

A: A reference to a fragment within the current document (e.g.
'#someelement'). If the referenced fragment is not within the current
SVG document fragment then whether the reference is an invalid IRI
reference or not is defined by the host language.



3. Typo in Linking section [LINKING]

In subsection "14.1.5 IRI reference attributes", "XLink" is mistyped.

Current wording:

xlink:type = 'simple'
    Identifies the type of XLink being used. In SVG Tiny 1.2, only
simple links are available. In line with the changes proposed in
XLiunk 1.1 [XLink11], this attribute may be omitted on simple links.

Proposed change:

xlink:type = 'simple'
    Identifies the type of XLink being used. In SVG Tiny 1.2, only
simple links are available. In line with the changes proposed in XLink
1.1 [XLink11], this attribute may be omitted on simple links.



4. Images mixed with text in linking section [LINKING]

Current markup:

<snippet1>
<p>The image below shows the correct rendering of the animation
example above. The arrows indicates the animation. The grayed
rectangles shows the initial state (i.e. time=0), the colored
rectangles shows the final state (animations are completed).
      <img src="examples/animation.png" alt="image showing usage of
the animation element" width="600" height="400">
      </p>
</snippet1>

<snippet2>
<p>The image below shows the correct rendering of the use example
above. The arrows indicates the animation. The grayed rectangles shows
the initial state (i.e. time=0), the colored rectangles shows the
final state (animations are completed).
      <img src="examples/use.png" alt="image showing usage of the use
element" height="400" width="600">
      </p>
</snippet2>

Proposed change:

<snippet1>
<p>The image below shows the correct rendering of the animation
example above. The arrows indicates the animation. The grayed
rectangles shows the initial state (i.e. time=0), the colored
rectangles shows the final state (animations are completed).<br />
      <img src="examples/animation.png" alt="image showing usage of
the animation element" width="600" height="400">
      </p>
</snippet1>

<snippet2>
<p>The image below shows the correct rendering of the use example
above. The arrows indicates the animation. The grayed rectangles shows
the initial state (i.e. time=0), the colored rectangles shows the
final state (animations are completed).<br />
      <img src="examples/use.png" alt="image showing usage of the use
element" height="400" width="600">
      </p>
</snippet2>

Of course this can probably fixed in a more elegant way by using CSS
(float the images right, for example).



5. W3C home page link change [LINKING]

Example "17_01.svg" uses a link which, while being somehow
"less-RESTful", will also cause an additional HTTP redirection
request.

Current markup:

<a xlink:href="http://www.w3.org">

Proposed change:

<a xlink:href="http://www.w3.org/">



6. Grammatical suggestion in Linking section [LINKING]

In subsection "14.3.2 SVG fragment identifiers", the verb to replace
doesn't seem to be properly conjugated (plus a minor suggestion).

Current wording:

An SVG fragment identifier must match the specified grammar. To ensure
robust content it is recommended that spaces between numeric values be
omitted or replace with percent encoded strings or commas as
appropriate.

Proposed change:

An SVG fragment identifier must match the specified grammar. To ensure
robust content it is recommended that spaces between numeric values
are omitted or replaced with percent encoded strings or commas as
appropriate.

I believe there's nothing wrong with the verb to be ("be" changed for
"are") - I guess it is a matter of preference. :-)




7. Minor inconsistency in Linking section [LINKING]

In subsection "14.3.2 SVG fragment identifiers", there's reference to
a situation already discarded by the previous premise. It is suggested
to remove the "is not found, or ".

Current wording:

If the SVG fragment identifier addresses any element (e.g., #rectId
or someDrawing.svg#rectId) and the element indicated by the fragment
identifier is found, then the current translation of the SVG
document's coordinate system shall be adjusted such that the
centerpoint of the decorated bounding box of the identified element is
positioned in the center of the viewport. If the element's decorated
bounding box is too large to fit within the current viewport, and the
'zoomAndPan' attribute of the rootmost 'svg' element is not set to
'disable', then the viewport shall not only reposition but also have
the current scale expanded to accommodate the entire width and height
of the element's decorated bounding box. By contrast, if the bounding
box of the target element is smaller than the viewport, the viewport
shall remain at the preestablished values (i.e., it will not
automatically zoom in on the element). If the specified element is not
found, or does not have a decorated bounding box, then the current
translate and current scale are not changed from the established
values. Regardless of changes to the current translation or scale of
the viewport, the current rotation of the current coordinate system
shall be preserved (that is, the centerpoint of the target decorated
bounding box shall be the centerpoint of the rotation, with a constant
rotation angle), and the existing aspect ratio shall not be altered.
In the case of traversal from an external link, the viewport shall be
established by the values specified in the rootmost 'svg' element, and
in the case of an internal link, the initial viewport shall
additionally be adjusted by any previous zooming operations (e.g.
previously navigated links, user zooming, script alterations of the
current coordinate system, etc.) such that any translation or scaling
that happens as a result of the traversal shall use the existing
coordinate system as a starting state. If the element is not found, or
does not have a decorated bounding box, then the viewport does not
move or zoom. In all cases of traversal, the view shall be established
instantly, with no animated panning or other enhanced transition
toward the target element. The viewbox shall not be continually
animated to match the animations of a target element's decorated
bounding box. Future specifications may allow more customizable
behavior for traversal through another mechanism.

Proposed change:

If the SVG fragment identifier addresses any element (e.g., #rectId
or someDrawing.svg#rectId) and the element indicated by the fragment
identifier is found, then the current translation of the SVG
document's coordinate system shall be adjusted such that the
centerpoint of the decorated bounding box of the identified element is
positioned in the center of the viewport. If the element's decorated
bounding box is too large to fit within the current viewport, and the
'zoomAndPan' attribute of the rootmost 'svg' element is not set to
'disable', then the viewport shall not only reposition but also have
the current scale expanded to accommodate the entire width and height
of the element's decorated bounding box. By contrast, if the bounding
box of the target element is smaller than the viewport, the viewport
shall remain at the preestablished values (i.e., it will not
automatically zoom in on the element). If the specified element is not
found, or does not have a decorated bounding box, then the current
translate and current scale are not changed from the established
values. Regardless of changes to the current translation or scale of
the viewport, the current rotation of the current coordinate system
shall be preserved (that is, the centerpoint of the target decorated
bounding box shall be the centerpoint of the rotation, with a constant
rotation angle), and the existing aspect ratio shall not be altered.
In the case of traversal from an external link, the viewport shall be
established by the values specified in the rootmost 'svg' element, and
in the case of an internal link, the initial viewport shall
additionally be adjusted by any previous zooming operations (e.g.
previously navigated links, user zooming, script alterations of the
current coordinate system, etc.) such that any translation or scaling
that happens as a result of the traversal shall use the existing
coordinate system as a starting state. If the element does not have a
decorated bounding box, then the viewport does not move or zoom. In
all cases of traversal, the view shall be established instantly, with
no animated panning or other enhanced transition toward the target
element. The viewbox shall not be continually animated to match the
animations of a target element's decorated bounding box. Future
specifications may allow more customizable behavior for traversal
through another mechanism.

I'd further suggest to try breaking this lengthy list item (possibly)
into several nested list items.



8. Elliptical arcs still referred to in minimize section [MINIMIZE]

Current wording:

SVG's path data definition was defined to produce a compact data
stream for vector graphics data: all commands are one character in
length; relative coordinates are available; separator characters do
not have to be supplied when tokens can be identified implicitly;
smooth curve formulations are available (cubic Béziers, quadratic
Béziers and elliptical arcs) to prevent the need to tessellate into
polylines; and shortcut formulations exist for common forms of cubic
Bézier segments, quadratic Bézier segments, and horizontal and
vertical straight line segments so that the minimum number of
coordinates need to be specified.

But arcs aren't available in this particular profile. Suggestion is to
remove this particular item resulting in:

SVG's path data definition was defined to produce a compact data
stream for vector graphics data: all commands are one character in
length; relative coordinates are available; separator characters do
not have to be supplied when tokens can be identified implicitly;
smooth curve formulations are available (cubic Béziers and quadratic
Béziers) to prevent the need to tessellate into polylines; and
shortcut formulations exist for common forms of cubic Bézier segments,
quadratic Bézier segments, and horizontal and vertical straight line
segments so that the minimum number of coordinates need to be
specified.



9. Inconsistent usage of quotes and/or apostrophe in markup

I noticed several inconsistent usages of the delimiter for attribute
values in XML markup. For example, in "entity.svg" [GENERAL], current
markup even shows both within the same document:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE svg [
    <!ENTITY Smile "
    <rect x='.5' y='.5' width='29' height='39' fill='black' stroke='red'/>

While I though the use of quotes was mandatory, it was quick to find a
similar example in the XML specification [XMLLANG], so it's probably
just an old myth in my mind. Few more samples of these mixed usage,
now in property definition [LINKING]:

xlink:type = 'simple'
[...]
target = '_replace' | '_self' | '_parent' | '_top' | '_blank' | "<frame-target>"
[...]
focusable = "true" | "false" | "auto"

Nevertheless, I'd generally recommend using the delimiter character
consistently. I can think of cases where simpler implementations,
which will tend to have less support for special (?) cases in XML
parsing, may potentially fail to render SVG content for a somehow
unrelated issue.



10. Unsorted minor issues [GENERAL]

10.1. Above average vertical spacing used for no apparent reason.
Known cases (there might be more): "sync-attr-main.svg",
"sync-attr-main.svg" and "navigation.svg".

10.2. Referencing SVG version "1.1". Known cases (there might be
more): "title-desc-tooltip.svg", "nohandler.svg".

10.3. Missing XML preamble. Known cases (there might be more):
"media02.svg", "media04.svg"



Best regards,

  Helder Magalhăes



[LATEST] http://dev.w3.org/SVG/profiles/1.2T/publish/linking.html
[AUTHORS] http://www.w3.org/TR/SVGMobile12/#AuthorList
[LINKING] http://www.w3.org/TR/SVGMobile12/linking.html
[MINIMIZE] http://www.w3.org/TR/SVGMobile12/minimize.html
[GENERAL] http://www.w3.org/TR/SVGMobile12/single-page.html
[XMLLANG] http://www.w3.org/TR/2006/REC-xml-20060816/#sec-lang-tag

Received on Monday, 13 October 2008 09:23:21 UTC