Wednesday, June 28, 2006, 1:22:00 PM, James Snell wrote:
> Hiding the div completely from users of Abdera would mean > potentially losing important data (e.g. the div may contain an xml:lang > or xml:base) I don't think that the div should contain an xml:base, because it isn't valid to use xml:base in XHTML 1.x. As the xhtml:div is added by the producer, it should be removed by the consumer, so there shouldn't be an xml:lang in there either. I wouldn't expect consumers to handle either consistently, so if you are a producer don't do it. I think in my implementation I handle lang and base on the div, and store them out-of-band, but it is more by accident than anything. I would hope that any other xmlns:* declarations on xhtml:div are honoured. Namespaces are so core to XML that making any recommendations about their placement is asking for trouble. > or forcing me to perform additional processing (pushing the > in-scope xml:lang/xml:base down to child elements of the div. I avoid that, it isn't nice as the xml:base will make the XHTML invalid and browser-dependant. In my RDF implementation, I store the lang context, base context, content model, and other stuff out-of-band from the content itself. I do rely on RDF's exclusive canonicalization rules though, to preserve the inscope namespace decls. (I assume that namespace decls aren't strictly allowed in valid XHTML either? Oh well...) > It also has ease-of-use ramifications on the API. So I really do > need a solid answer on this one. You need to preserve a load of context in addition to the content string itself, so expect to have to return these extra properties for each use of Text Constructs in your API. It is a bit of a high-barrier to entry really. (If Atom had been designed in JSON, instead of XML, I wonder if it would have been more sympathetic to the OO/RDBMS crowd, and whether we would have bothered with such fine-grained language tagging?) -- Dave
