W3C home > Mailing lists > Public > public-openannotation@w3.org > June 2020

Re: SVG selectors and namespaces handling

From: Gerben <gerben@treora.com>
Date: Thu, 25 Jun 2020 18:28:41 +0200
To: public-openannotation@w3.org
Message-ID: <60ce10ee-1ef1-b9af-03ca-e12defbc7cec@treora.com>
Hi Rainer, great to see Annotorious being ‘rebooted’. I am not an expert
on SVG or XML, but I got curious myself and will contribute my
observations from checking the specs. :)

The Web Annotation Model you linked to states that the value property
“/MUST/ be well-formed SVG XML”, where SVG refers to SVG 1.1.

Looking at the SVG 1.1 spec, there appears no mention of an ‘implicit’
namespace. Rather, it explicitly requires declaring the namespace[1]:

    In all cases, for compliance with the Namespaces in XML
    Recommendation [XML-NS], an SVG namespace declaration must be
    provided so that all SVG elements are identified as belonging to the
    SVG namespace. The following are possible ways to provide a
    namespace declaration. An ‘xmlns’ attribute without a namespace
    prefix could be specified on an ‘svg’ element, which means that SVG
    is the default namespace for all elements within the scope of the
    element with the ‘xmlns’ attribute:

    <svg xmlns="http://www.w3.org/2000/svg" …>
      <rect …/>
    </svg>

    If a namespace prefix is specified on the ‘xmlns’ attribute (e.g.,
    |xmlns:svg="http://www.w3.org/2000/svg"|), then the corresponding
    namespace is not the default namespace, so an explicit namespace
    prefix must be assigned to the elements:

    <svg:svg xmlns:svg="http://www.w3.org/2000/svg" …>
      <svg:rect …/>
    </svg:svg>

So I suppose the example would indeed not qualify as well-formed. I
don’t know if ‘well-formed SVG XML’ also implies the need for the <?xml
…> tag, which the example does not contain either.

Moreover, the spec seems rather short about how to interpret SVG
contents as shapes; I hope it is sufficiently clear to implement it.

In any case, I suppose that implementations would do best by following
the adage “be conservative in what you do, be liberal in what you accept
from others”; e.g. in absence of declarations, we could default to the
svg 1.1 namespace for the ‘svg:’ prefix, as well as for the default
namespace. And perhaps some day the spec could be updated or extended to
be more precise. It would be great if you could document and share
details of how Annotorious interprets the spec, to help others create
compatible implementations!

Regards,

— Gerben

[1]:
https://www.w3.org/TR/2011/REC-SVG11-20110816/struct.html#NewDocumentOverview


On 21/06/2020 11:05, Rainer Simon wrote:
> Dear list,
>
> I'm adding support for SVG shapes to Annotorious [1] and have a
> question regarding the handling of the namespace when embedding SVG in
> the SvgSelector.
>
> The example in the documentation [2] doesn't declare a namespace, but
> it does use a prefix:
>
> <svg:svg>...</svg:svg>
>
> Is the use of "svg" as a prefix + no declaration of the namespace an
> existing convention for SvgSelectors? If there is a convention around
> omitting the namespace, wouldn't it be more straightforward to
> consider the default namespace to be SVG? (Especially since the svg
> prefix needs to be repeated for every child element?) I.e. Simplifying
> the example to: 
>
> <svg> ... </svg>
>
> Or, alternatively, should implementers instead be required to include
> the namespace declaration in the embedded SVG? E.g.
>
> <svg:svg xmlns:svg='http://www.w3.org/2000/svg'> ... </svg:svg>
>
> This would leave possibilities open for different prefixes, if
> implementers choose to use them. Or set SVG as the default namespace. 
>
> But having a convention on *both* the prefix value to use in the
> selector *and* the omission of the namespace URI seems like one
> convention too many. Or am I on the wrong path here?
>
> Cheers & thanks in advance,
> Rainer
>
> [1] https://recogito.github.io/annotorious/
> [2] https://www.w3.org/TR/annotation-model/#svg-selector
Received on Thursday, 25 June 2020 16:28:58 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 25 June 2020 16:28:59 UTC