On Aug 14, 7:24 pm, Stephen Compall <[email protected]> wrote: > Maciej Katafiasz <[email protected]> writes: > > but then the problem is that Stephen's work is based on CXML, and not > > closure-html. Stephen, why exactly is that? The problem is that > > weblocks does not output XHTML[*] but HTML, and browsers see it as > > such. Thus it should be parsed by a HTML parser. > > Yes, Weblocks sends HTML instead of XHTML, and browsers will parse the > output with an HTML parser rather than an XML parser. But as far as I'm > concerned, if it looks like XML, walks like XML, and quacks like XML, > it's XML.
Except you're wrong. It's not any more correct than insisting a CLtL1 programme is ANSI CL programme too. They walk and quack the same to a large extent, but there are important differences. HTML is only equivalent to XML if you are comparing fully valid HTML5 (not 4.01) and XHTML parsed by a validating parser resolving all the internal subsets business while avoiding namespacing and mixins from other XML dialects. Otherwise things as simple as character entities can and will trip you up. Not to mention error handling and recovery. > The reason for my choice is that unifying XML is more generally useful > than unifying HTML. In particular, it can be used as a replacement for > accessing the DOM API directly in XML-using applications, which can be > quite tedious when you're trying to extract information from a complex > document, or build a document. Fair enough, but that means there needs to be explicit glue transforming Weblocks's HTML into XML before unification. chtml can transform into cxml trivially, so fortunately that's a very simple step, but it needs to be there. Otherwise the results are *wrong*. It might be that I misunderstood your intentions and scope of the project, and you never meant it to be in any way Weblocks-exclusive or centered, but the point remains. Any use of cxml-unification for Weblocks must be preceded by parsing the output with chtml first. > Scraping and constructing HTML is > certainly useful, but it is only one use, and the transform between > general HTML to XHTML is well-understood, whereas transforming general > non-XHTML XML to HTML is not. > > What remains of cxml unification is to write LIFT unit tests, and the > WHO-compatible input syntax, without which constructing template DOM > trees is quite tedious. Any ETA on that? I must say the whole templates business in cl- unification I find quite confusing; it might be bad examples or something, but as soon as they get to structure templates, they cease making any sense to me. I haven't invested enough time into it yet actually to run the whole thing and try to poke it into submission, but that's my impression. A related question, why exactly do you need #U? All it does is READ things in the context of the unification package, why is it necessary and why do you need a whole reader macro for that? Also, speaking of LIFT, how much of our current testing infrastructure is directly tied into LIFT? It'd be a good thing to ensure all the helpers a'la WITH-REQUEST are completely independent of the particular unit testing framework; myself I use Stefil and would be pretty unhappy to be forced to move to LIFT to be able to test Weblocks apps. That's a task that goes together with making sure the helpers are a public API and exported. I might look into doing it, but no promises I'll be able to. Cheers, Maciej --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "weblocks" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/weblocks?hl=en -~----------~----~----~----~------~----~------~--~---
