Re: New Draft comments: Specific Resources

Sorry, but I'm confused!

>> However I agree in that styles do not make the resource "more
>> specific" - it is more of a kind of modularity. So your suggestion is
>> to simply rename the chapter to "Specifiers" and keep the classname
>> oa:SpecificResource? (as styles are attached to annotation) I can +1
>> that.
>
> This was indeed my suggestion. I'm not fond of the oa:SpecificResource class
> in the first place, see other comments. But at least we'd convey the message
> that specifiers can function differently from selectors.

I renamed the module.

By the last sentence do you mean that it's unclear that there can be
Specifiers which are not Selectors?

Also, I don't think I fully grasp your dissatisfaction with the
Specific Resource class -- is it the name, or its existence?  I take
it that you do feel that the node in the graph is required, though?



>> Agreed - this text should be softened to highlight that this is the
>> preferred way to interpret the specific resource and styles for
>> traditional rendering, but that agents MAY choose to interpret the
>> specifiers differently.

I think this is already in the spec. Unless you disagree with:

If both exist, then they should be processed in that order, and the
result is the resource identified by the Specific Resource's URI.

(We could make it SHOULD, but that section seems more descriptive than
prescriptive)

The rationale for the workflow is that segments are almost always
about representations, not resources.  The same resource could provide
both image, pdf and plain text representations, which would require
very different selectors to pick out the intended segment.  Hence, it
is necessary to consider the State information first in order to
retrieve the appropriate representation from the resource's URI.

>> Section 3.4 on styles does also not preclude
>> styling that is not about the body or target - so it might be worth
>> breaking the diagram in two by doing the last rendering/styling step
>> separately from the annotation instead.
>
> Yep, that's also what I think.

I would propose just dropping the diagram at that point -- it wouldn't
make it any clearer than the surrounding text.

However, while section 3.4 doesn't preclude styles that aren't about
body or target, the only implementation of them does, as a
SpecificResource is required for oa:styleClass.

We could drop the abstract class sections from the spec and have them
only in the ontology, eg sections 3.2 3.3 and 3.4 and promote their
subsections. Or we could make the descriptions more explicit that
they're not intended to be used directly.  I would prefer the latter,
as there may be future Selectors, States and Styles that build off
them.

Rob

Received on Thursday, 24 January 2013 18:56:28 UTC