Re: [widgets] [preference element] question on the value attribute

In practice, we've been serialising data into JSON and storing it in a  
preference as text content whenever we've needed a preference value to  
contain structured information.

Having the content of the preference value as text content at least  
makes it easier to know how to start de/serializing it. Arbitrary  
structured XML/HTML would be a real pain to implement. Escaping XML or  
serialising preference values in some other fashion seems less painful.

S

On 24 Jun 2009, at 17:03, Robin Berjon wrote:

> On Jun 24, 2009, at 14:16 , Jean-Claude Dufourd wrote:
>> Robin Berjon a écrit :
>>> If by text content you mean actual text content, then there is no  
>>> difference whatsoever between what can be stored in an attribute  
>>> value and the text content (as per DOM 3 textContent) of an  
>>> element — at least not semantically.
>> JCD: I think I agree with you Robin, but Marcos writes something  
>> different.
>
> Which, obviously, means that Marcos must be wrong. Attributes can  
> contain the same text as element content (though some syntactical  
> details may vary).
>
>> In the IDL, both are DOMStrings right ? Is there spec text limiting  
>> attributes ? I cannot find a
>
> I'm not sure what you mean by "in the IDL" since this is an XML  
> question and is therefore entirely unrelated to APIs. In A+E,  
> preferences are returned as DOMStrings indeed, but that is  
> orthogonal to the value space of the way in which it is captured in  
> syntax. In fact, the value space of DOMStrings is larger than that  
> which can be encoded in XML text anyway.
>
>>> If by text content you mean structured content, then we're talking  
>>> about turning the preference system into an XML storage system  
>>> since most XML constructs could appear there.
>> JCD: Are you not contradicting yourself ? If the two are identical  
>> in storing possibilities, there should be no difference (if  
>> appropriate quoting of special characters is applied).
>
> No. They have the same storage for *text content*. But elements can  
> contain a bunch of things that attributes can't: elements,  
> processing instructions, comments, CDATA sections...
>
>>> Do you mind clarifying which one it is you are wondering about?
>> JCD: It is indeed a question of allowing the users (users of widget  
>> spec = authors actually) to place anything in the value of a  
>> preference, including bits of XML or whatever that needs a CDATA  
>> section around it to fit in an XML file.
>
> You can indeed place anything unstructured inside the value of a  
> preference (irrespective of which approach might be taken).
>
>> To reformulate my current understanding, informed by your answer,  
>> using an attribute vs. the text content is equivalent in terms of  
>> which strings are allowed, but the attribute format is more  
>> difficult to express (because more intricate quoting is needed)  
>> than the text content.
>
> I would hardly call quote escaping intricate (it's only one extra  
> rule compared to element content). An attribute can be seen as  
> semantically preferable here as the value is not intended to be  
> structured or extensible.
>
> -- 
> Robin Berjon - http://berjon.com/
>    Feel like hiring me? Go to http://robineko.com/
>
>
>
>
>
>