Re: Style

You asked for a solution for Shannon's use case, and for those SVG should work.

But let me briefly respond to the other reasons you are mentioning:
 
> I don't think this is a real solution for several reasons, primarily:
> 
> * Doesn't work for non fixed pixel data (eg white border around text
> on white reflowable page)

I am not sure, if I correctly understand that use case, but if you mean sth
like this (http://www.schepers.cc/svg/blendups/overlay/test/overlap.xhtml),
then you see that it is possible.
 
> * Would mean that everyone had to support SVG, making media fragments pointless

Our custom CSS-in-RDF solution means that everyone has to support CSS parsing from
an RDF graph. I don't see why SVGFragments make media fragments pointless. You can
still use MF for use cases in which you don't need styling info. If you really need style,
then, yes, you have to buy into SVG. I could also imaging to represent the fragments twice,
once as simple media fragment identifier and once as SVG fragment. Then you gain the
nice fall-back behavior that clients that don't understand SVG can at lest render the non-styled
SVG fragments.
> * Is worse for separation of concerns (semantic/presentation) than the
> current proposal

At the moment we define presentation-oriented information in a data/semantics-oriented data
model, which means that concerns are not separated. If we "outsource" styling of fragments
to standards that support this, such as SVG, then we don't need to introduce presentation-oriented
properties / classes (oax:hasStyle, oa:style). So the definition of presentation-oriented information
lives orthogonal to the definition of data/semantic-oriented information. I would say that the latter
is a better separation of concerns.
> * It's harder to ignore, as it's embedded within the SVG selector XML
> rather than linked from the Annotation

I don't see why it is hard to ignore information.
 
> * It doesn't allow 'inverse' styles, important for things like medical
> images, where you grey out the rest of the resource rather than
> putting a semi-transparent colored area over top of the selected
> fragment, distorting the visible information.

I am sure that there will always be potential use cases for which CSS and/or SVG won't work and
maybe additional fragments selector types need to be defined for them. It is hard to make judgments
without seeing the use case without knowing the content and the annotations. But with SVG you can really
do a lot; just look at Adobe Illustrator.
> 
> Rob 
Bernhard

Received on Friday, 7 September 2012 18:12:59 UTC