>>>For 1., I agree that behavior is a separate issue, but turning a URI
>>>into a URL is a common enough occurence that it's worth including in
>>>core. I am going to include it since I think we've all pretty much
>>>stated our agreement and consider the matter resolved.
>>
>>Yes. Wouldn't there be some XLink term we could reuse here? (just
>>wondering).
>
> Yes, we should have something like that in Fresnel. Any concrete solution OK
> with me.
Is there an XLink term you're thinking of, Emmanuel? I'm not very
familiar with that spec.
>>>For 2., I ultimately proposed what's in:
>>>
>>>http://simile.mit.edu/mail/ReadMsg?listName=General&msgNo=486
>>>
>>>Agreeing on a name for this set of terms is also an important task. I
>>>don't much care what that name is.
>>
>>You mean "PropertyTransform"?
>
> I'm open to having the Style vocabulary split. But I don't see a big
> difference between a style and a propertyTransform as long as the
> propertyTransform also has a transformDomain.
I think it really only makes sense in the context of shifting the rest
of the style vocabulary out of core...
> Ryan: Could you provide an more complete example than in the cited post on
> how PropertyTransform would be used?
(will write an example tomorrow)
>>>For 3., we come back a bit to the intermediate tree. If we are going to
>>>have a class attribute on tree elements, then we need a way to assign a
>>>value to that class in core. Back to hooks - I propose fresnel:hook
>>>"foo"^^xsd:string on a lens.
>>
>>"hook" seems a little bit too general for me. Could we introduce the
>>notion of styling in it? Maybe "stylingHook", or "classHook".
True enough. stylingHook sounds appropriate.
> Where exactly would you use this property? How would you style a lens with a
> single hook to a CSS class? I think it would also be cool to have an
> extended example, so that we can dicuss pros and cons.
I imagine there are different points at which you would use a hook so
you could attach a class at different points in an intermediate tree.
(will write an example tomorrow)
>>>4. I've already added primaryClasses to the core vocab but I don't
>>>recall hearing agreement that it's the right thing to do from all.
>>
>>What was it about? I don't remember this.
>
> The issue was to define some classes as primary (like foaf:Person) and have
> the other as secodnard classes (like vCard:adress), which would give the
> browser hints on where to start.
>
> I'm not totally convinced that we need this. But it is OK with me if Ryan
> wants to put it in.
Consider it added and resolved, then.
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,
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.
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?
--
Ryan Lee ryanlee_at_w3.org
W3C Research Engineer +1.617.253.5327
http://simile.mit.edu/
Received on Fri May 13 2005 - 04:23:33 EDT