Emmanuel Pietriga wrote:
> Ryan Lee wrote:
>> Stefano Mazzocchi wrote:
>>
>>> Ryan Lee wrote:
>>>
>>> I don't know what the end goal of this is, but I'll look at it from a
>>> publishing-ease point of view.
>>>
>>>> <?xml version="1.0" encoding="iso-8859-1"?>
>>>> <!DOCTYPE results PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
>>>> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
>>>>
>>>> <!-- comments welcome... -->
>>>>
>>>> <results xmlns="http://www.w3.org/2004/09/fresnel-tree">
>>>> <resource class="this-resource">
>>>> <title>Ryan Lee</title>
>>>> <content>
>>>> <before>Person: </before>
>>>> </content>
>>>
>>>
>>> how about <title><content type="before">Person: </content>Ryan
>>> Lee</title> instead? (type="before") so that it could be
>>> differentiated from type="after".
>>
>>
>> Are you also suggesting <title>Ryan Lee<content type="after"> is a
>> person</content></title>?
>
> Isn't that redundant?
>
> I think you would either have (order of title's children does not matter):
>
> <title><content type="before">Person: </content><content type="after">
> rules.</content>Ryan Lee</title>
>
> or (order matters since there is no explicit before/after information):
>
> <title><content>Person: </content>Ryan Lee<content>
> rules.</content></title>
>
> I don't quite like the 2nd one as the <content> markup looks like
> over-structuring to me (it does not bring much relevant information per
> se). Besides, the 2nd one means that all content has been "expanded",
> there is no such thing as a before/after/first/last thing any longer.
Good point - if we did it the second way, we'd be resolving the content
part before the next consumer saw it. Do we want to do that so it can
be semi-useful out of the box?
>> The placement of 'content' elements is quite intentional - the content
>> modification is related to the element's parent, so the 'content'
>> element inside the 'values' element only applies to value items for
>> before and after types; first and last apply to the set. This was to
>> keep repeated strings from bloating the results.
>> I guess it's a trade off between compactness and immediate usability -
>> to do it the way it's currently done assumes somebody will transform
>> the tree later before showing it to users.
>
> I do like this, though people might not like the idea that they have to
> do additional processing to get the actual presentation tree.
...or is keeping bloat down more important?
>>>> <property class="this-property"
>>>> uri="http://xmlns.com/foaf/0.1/name">
>>>> <content/>
>>>> <label class="this-label">
>>>> <content/>
>>>> <title>name</title>
>>>
>>>
>>>
>>> and here just <title>name</title> indicates that there is no content.
>>
>>
>> I agree and should probably fix that.
>
> Definitely.
Fixed.
--
Ryan Lee ryanlee_at_w3.org
W3C Research Engineer +1.617.253.5327
http://simile.mit.edu/
Received on Wed Sep 14 2005 - 19:23:23 EDT