Allow full SVG in SvgSelector?

[azaroth42]

Should the SvgSelector allow multiple shapes? (From Doug via annotation)

Discussion:
The rationale for this in the CG was that multiple non-overlapping/grouped shapes should probably be multiple targets, each with their own selector.

[tilgovi]

I could see multiple targets any of which may or may not have contiguous geometry. Why prevent it?

[stain]

as long as it can be expressed in SVG, it should be fine. We can't make our own "SVG profiles" that requires shapes to be continuous or something.

[azaroth42]

The discussion during the CG was that multiple non-contiguous shapes should be separate targets in the model, to avoid multiple ways of expressing the same thing (multiple targets) and to ensure that each target region had the opportunity for identity (via the SpecificResource).

If we don't feel those are important distinctions to maintain, then we can drop the single shape requirement.

[stain]

I think it becomes a difficult thing to enforce or check. What might at
first glance in the SVG look like non-contiguous, could be shown to be
contiguous in rendering - for instance a trianglethat is close to a circle

• you will need to do precise calculations to see if it is a contiguous
  shape or not - but why should it matter?

Perhaps the best is to simply keep it as "Multiple non-contiguous shapes
SHOULD be separate targets, this ensures that each target region gets an
identity".

On 8 April 2015 at 15:56, Rob Sanderson notifications@github.com wrote:

The discussion during the CG was that multiple non-contiguous shapes
should be separate targets in the model, to avoid multiple ways of
expressing the same thing (multiple targets) and to ensure that each target
region had the opportunity for identity (via the SpecificResource).

If we don't feel those are important distinctions to maintain, then we can
drop the single shape requirement.

—
Reply to this email directly or view it on GitHub
#17 (comment).

Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/0000-0001-9842-9718

[jjett]

+1 for this. I agree that it will be hard to enforce, which makes me think
its within the boundaries of best practice rather than something the data
model can outright forbid.

On Thu, Apr 9, 2015 at 4:26 AM, Stian Soiland-Reyes <
notifications@github.com> wrote:

I think it becomes a difficult thing to enforce or check. What might at
first glance in the SVG look like non-contiguous, could be shown to be
contiguous in rendering - for instance a trianglethat is close to a circle

• you will need to do precise calculations to see if it is a contiguous
  shape or not - but why should it matter?

Perhaps the best is to simply keep it as "Multiple non-contiguous shapes
SHOULD be separate targets, this ensures that each target region gets an
identity".

On 8 April 2015 at 15:56, Rob Sanderson notifications@github.com wrote:

The discussion during the CG was that multiple non-contiguous shapes
should be separate targets in the model, to avoid multiple ways of
expressing the same thing (multiple targets) and to ensure that each
target
region had the opportunity for identity (via the SpecificResource).

If we don't feel those are important distinctions to maintain, then we
can
drop the single shape requirement.

—
Reply to this email directly or view it on GitHub
#17 (comment).

Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/0000-0001-9842-9718

—
Reply to this email directly or view it on GitHub
#17 (comment).

[pciccarese]

I am inclined to agree with Stian point as well. It would be nice to have always the same behavior but if we cannot validate it easily we cannot enforce it either. I have not implemented SVG selectors myself so I would rather rely on the opinion of who did or tried to. For instance, I am not sure on what would happen to a client, which expects one shape only, when multiple shapes are defined in the same target.

[azaroth42]

So no change, and leave as a SHOULD/RECOMMEND. Fine by me. Will leave the issue open in case others want to chime in to disagree, but will close (wontfix) next week if there's no further discussion.

[azaroth42]

Resolved in October WD.