W3C home > Mailing lists > Public > public-openannotation@w3.org > December 2012

Style Issue

From: Robert Sanderson <azaroth42@gmail.com>
Date: Thu, 20 Dec 2012 09:15:17 -0700
Message-ID: <CABevsUHmy9o8X=3wxyU0Cb=kEK5Xq-XffK3JWu2YxF69Supyqw@mail.gmail.com>
To: public-openannotation <public-openannotation@w3.org>
Dear all,

While writing up the new method of attaching Styles to Annotations, we ran
into the following unanticipated issues.  We feel this makes the current
solution for style unworkable, and propose a slight modification that
should make things easier all round.

Issues:

1.  Styles reference the resources in the graph by URI, using the CSS
@document rule.  While this makes matching easy, it becomes impossible with
the republishing method that is recommended in the specification.

For example, a system publishes an Annotation A with an embedded body
URN:B.  URN:B is thus the URI that is in the Style.

A second system harvests the Annotation, republishes it at A2, and the body
as a web resource at HTTP URI B2.  It should also assert that B2
equivalentTo URN:B.  So now the style refers to the equivalent resource,
not the body itself and systems will always have to check both.
This isn't the end, however, as this is likely to happen multiple times in
a distributed system.
The Style could be updated, but it might be a web resource that is
maintained outside of the annotation system and these changes would not be
reflected in the copies.  It also relies on consuming systems to understand
the content of Styles, which seems above and beyond what they should be
expected to do.


2.  As Styles refer to the URI of the resource, they cannot be re-used
across multiple annotations.  This means that there necessarily must be one
style per annotation, which is contrary to most uses of CSS and really to
the web architecture in general.  So every system that has a style for its
annotations must create a new style resource for each annotation, rather
than just a default few.


3.  Following from 2, there is no reason to *not* embed the style if it is
tied 1:1 to the Annotation. This defeats the purpose of some of the changes
from the first draft, eg to make it a valid CSS resource rather than just
the value block.  It also brings up a (lesser) documentation/learning issue
that to understand Styles you need to understand the Content in RDF model,
which otherwise is not necessary.

We consider the sum of these issues to be a show-stopper.
Our proposal for how to adapt it is:

1.  Keep the Style resource a valid CSS document attached to the
Annotation, still using oa:styledBy, as in the current proposal.

2.  Instead of using the complex @document url() rule construction, instead
use the more familiar class name construction.

3.  Have a property in the Annotation graph on the resources to be styled
that records the class name.   Systems then match the property to the
respective name in the CSS document.

This solves Issue 1 because the property can be reattached easily to the
new resource, just like all of the other properties and relationships.  At
the same time, we use only basic CSS constructions rather than the CSS
Level 3 @document construction.

It solves Issue 2 because the class names can be re-used across multiple
annotations.  I also makes it easier to swap styles across a range of
annotations -- simply change the referenced CSS resource and they all
change, rather than the current method (edit all of the embedded CSS blobs)
or the first version (change the references on all of the Specific
Resources).

It solves Issue 3 by solving Issue 2, as the style is not tied 1:1 with the
Annotation.

Thus:
_:Anno a oa:Annotation ;
  oa:styledBy <Style1> ;
  oa:hasTarget <SpTarget1> ;
  oa:hasBody <Body1> .

<SpTarget1> a oa:SpecificResource ;
  oa:hasSelector <Selector1> ;
  oa:styleClass "red" ;
  oa:hasSource <Target1> .
...

Where Style1 has the representation:
.red { color : red }

This seems to capture the best parts of the current proposal while solving
the issues that have come up with it.

Please let us know any thoughts or comments on this revised approach.

Many thanks,

Rob, Paolo and Herbert
Received on Thursday, 20 December 2012 16:15:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 20 December 2012 16:15:46 GMT