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/
