Re: Style

I think a CSS Selector would be very useful.  (A CSS-Selector
Selector, really!)  We should add it in the next version of the
Extension document.

I'm not sure that the XSLT selector is much more useful than an
xpointer fragment selector, are there any significant use cases for
when xpointer/xpath is insufficient?

I would like to keep oa:hasStyle in the core document, but would not
object terribly to having it part of the extension document.

Rob

On Wed, Aug 1, 2012 at 8:22 AM, Tim Cole <t-cole3@illinois.edu> wrote:
> One further consideration in favor of proposal to remove oa:hasStyle from specificTarget and specificBody (and attaching instead to oa:Annotation) -- doing this would also remove the temptation to conflate or at least overlap the intent of oa:hasStyle and oa:hasSelector. For example, given the following HTML in your annotation target resource:
>
> ...
> <div id="content">
>    <p lang="en">Hello World</p>
>    <p lang="fr">Bonjour le Monde</p>
>    <p lang="de">Hallo Welt</p>
> </div> ...
>
> You could use (in fact might be most efficient to use) any of the following CSS snippets (CSS Selectors) to select the French language Hello World paragraph:
>
> div#content p:lang(fr)  – CSS2
> div#content p[lang^="fr"] – CSS3
> div#content p:nth-child(2) – CSS3
>
> In the current model, the temptation is to include such CSS on a specificTarget as part of Style, because intuitively that's where most CSS goes. But if your intent is to select for annotation just the French language Hello World paragraph, the more correct approach, I think would be to define a CSS type for Selector. Similar argument for XSLT designed to select rather than style, though here there may be an important distinction to be made between "selection" and "transform", in which case the right thing to do might be to define an XPath (rather than an XSLT) Selector type since by definition the result of evaluating an XPath expression is to "select" while XSLT is "a language for transforming."
>
> So, I also concur with the consensus so far that presentation is more a property of the Annotation than of a SpecificTarget or SpecificBody. But regardless, I think we need to consider whether XPath and CSS selectors might be appropriate as within the range for oa:hasSelector.
>
> Potential problems or concerns with using XPath and the selector part of CSS this way?
>
> Tim Cole
> University of Illinois at UC
>
>
> -----Original Message-----
> From: stian@mygrid.org.uk [mailto:stian@mygrid.org.uk] On Behalf Of Stian Soiland-Reyes
> Sent: Wednesday, August 01, 2012 3:21 AM
> To: Robert Sanderson
> Cc: public-openannotation
> Subject: Re: Style
>
> I agree on this approach, to foster reuse of a specific resource.
>
> I have run into the same issue, in particular for the cases where the specific resource has its own (typically non-information-like) URI as well, as we have discussed here.
>
>
> Perhaps as hasStyle would not really apply to any kind of annotation, mainly visual/highlight ones, its domain could be a subclass StyledAnnotation, of which subclasses could be oax:Highlight. (Some instances of other subclasses could of course also be StyledAnnotation). From this I wonder if hasStyle should move to oax:
> as well - but perhaps not, as we would want anyone who does styling to use hasStyle as a starting point.
>
>
> On Mon, Jul 30, 2012 at 5:19 PM, Robert Sanderson <azaroth42@gmail.com> wrote:
>>
>> [Moderator bouncing message, stripped of attachment which was to big
>> for mailing list size limit.
>>  The attachment is archived at:
>> <http://lists.w3.org/Archives/Public/www-archive/2012Jul/att-0038/prop
>> osal_style.png>]
>>
>> Dear all,
>>
>> There was an offline discussion last week concerning the current use
>> of oa:hasStyle being attached to the Specific Resources which we
>> should continue online in the larger group.
>>
>> The concerns that were raised with the current model for style:
>>
>> * Specific Resource nodes cannot be re-used between annotations, as
>> someone might attach a Style to it in another annotation, thereby
>> changing all of the uses of the Specific Resource.  If the nodes
>> cannot be reused, then they're significantly less valuable
>> (essentially they may as well be blank nodes!)
>> * The Specific Resources would then identify the section of the
>> representation, rather than a styled section of the representation.
>>
>> * Conceptually the style is for the Annotation.  It would be cleaner
>> if it were attached to the Annotation rather than the individual
>> Specific Resources.
>> * It would thus be somewhat easier to ignore for clients that don't
>> expect to process it.
>>
>> * The CssValueStyle class is a nasty hack -- it's not a valid CSS
>> file.  If we're just creating our own hack, we can do it in a
>> different way just as easily.
>>
>>
>> And after some discussion the proposed change was:
>>
>> Instead of attaching to the Specific Resource, oa:hasStyle would
>> attach to the Annotation.  The object of the relationship would be a
>> valid CSS file that describes all of the stylistic features for the
>> resources that are part of the annotation graph.
>> A diagram form is attached.
>>
>> There is a slight loss in functionality if we adopt this approach, as
>> any alternative style format would need a means to address the
>> resources in the annotation graph.  Thus it would be more difficult to
>> use, for example, XSLT as a styling language.
>>
>> The current requirements from the use cases and stakeholders are only
>> for describing stylistic or rendering features, rather than arbitrary
>> transformations.  For example, red strike-through and yellow
>> background is required, but we don't have a strong case for
>> transformation of arbitrary XML into HTML or JPEG into PNG.
>>
>> Please weigh in with your thoughts!
>>
>> Thanks,
>> Rob & Paolo
>>
>
>
>
> --
> Stian Soiland-Reyes, myGrid team
> School of Computer Science
> The University of Manchester
>
>

Received on Wednesday, 1 August 2012 19:09:41 UTC