Ryan Lee wrote:
> 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?
What about offering a pipeline, allowing users to take their data either
before or after resolving the content part ?
Both formats (which might actually only be one since there does not seem
to be that much difference between the two) would be defined explicitly,
but the content-resolving step (in which you loose some information from
the perspective of what layout was intended) would be optional.
Emmanuel
--
Emmanuel Pietriga
INRIA Futurs - Projet In Situ tel : +33 1 69 15 34 66
Bat 490, Université Paris-Sud fax : +33 1 69 15 65 86
91405 ORSAY Cedex FRANCE http://www.lri.fr/~pietriga
Received on Thu Sep 15 2005 - 06:44:46 EDT