>>I came up with a couple new issues while looking over my style parsing
>>code.
>>
>>5. styleDomain and... styleResourceDomain? We make a distinction for
>>different kinds of lenses (class vs. instance domain) but we don't for
>>styling resources vs. styling properties. I wonder if we'd also have to
>>distinguish styling classes vs. styling instances,
>
>
> We argued about the necessity of having both lensDomain and
> instanceLensDomain. I was against it because with FSL you could
> unambiguously express both, but we eventually agreed to keep it as FSL
> is not a must-be-supported selection language (only simple naming is).
>
> If we have such a thing for lenses, I guess we should have it for
> styles. And you're right, there is even more ambiguity here. Does the
> style apply to the resource with URI A, to all resources that are
> instances of class refered to by URI A, or to properties identified by
> URI A? We probably want to express all of these, so we need vocabulary
> constructs for them.
>
> We could have:
> - classStyleDomain
> - instanceStyleDomain
> - propertyStyleDomain
>
>
> Chris: We already have this. See:
> http://simile.mit.edu/repository/fresnel/trunk/docs/manual/FresnelVocabulary
> .htm#classstyle
Ah, sorry I forgot we'd already gone down this path. Doesn't this
effectively render fresnel:resourceStyle useless in core? Or see below
in regards to nixing the box model.
> and I think it would be better to have:
> - classLensDomain (as opposed to lensDomain)
> - instanceLensDomain
>
> Chris: We already discussed this and descided that leaving the "class" out
> is a usefull abbreviation, because it is the usual case.
>
>
>
>>6. Non-existent styleDomain for some styles. This does make sense if a
>>style is only used in a fresnel:use relationship, but *Domain has been
>>the definining one-step inference in implementation so far. Could we
>>possibly say something like fresnel:styleDomain fresnel:null, where the
>>idea is that the domain of the style is considered irrelevant? The
>>style wouldn't be applied except where specified in fresnel:use.
>
> Can't we just intepret the lack of fresnel:*Domain as the domain of a
> style being irrelevant?
fresnel:*Domain is a direct indication of the type of a resource.
Without it, I can't tell what the resource is.
I suppose an additional means of inference is to say the object of
fresnel:use is a style, but the examples and the documentation don't
bear that out precisely - the manual appears to state the object of
fresnel:use is a fresnel:Group, but a later statement says the object
can be a fresnel:Style, using an example out of the examples directory
(search in-document for fresnel:use).
Is it supposed to be both? If it is, or if it's supposed to be just
groups, I can't use it for inferencing style type.
>>7. {container,property,etc.}Style are used to refer to a
>><something.css#a> resource in Chris' examples, I'm not sure what that's
>>supposed to mean. Sorry for not remembering; I don't recall how that
>>was supposed to accomplish something in practice?
>
> These terms are closely related to the box model. This isn't to be part
> of core.
Do we all agree that they're being removed from core?
> Chris: Yes, the terms do the same on styles that you want to do with your
> CSS hooks on lenses.
>
> <something.css#a> was a hack to refer to a style class in an external
> stylesheet. The example is outdated. We changed the design to:
>
> :foafGroup rdf:type fresnel:Group ;
> fresnel:stylesheetLink <http://www.example.org/example.css> .
>
> :uriStyle rdf:type fresnel:Style ;
> fresnel:styleDomain foaf:homepage ;
> fresnel:labelStyle "basicLabel"^^fresnel:styleClass ;
> fresnel:valueStyle "basicUri"^^fresnel:styleClass ;
> fresnel:group :foafGroup .
>
> See:
> http://simile.mit.edu/repository/fresnel/trunk/docs/manual/FresnelVocabulary
> .htm#csshooking
Got it, thanks for clearing that up.
Can we clean up the examples or make it a near-term goal to get them
completely in synch with the documentation?
--
Ryan Lee ryanlee_at_w3.org
W3C Research Engineer +1.617.253.5327
http://simile.mit.edu/
Received on Fri May 13 2005 - 17:14:32 EDT