Hi Zope Gurus, After looking over all the HiperDOM / xmlc stuff I think I'm starting to "get it". I'll just summarize the things that ring especially true for me, with some comments Re. letting HTML "Page" Designers use familiar tools: "Note that XMLC depends on legal HTML/XML markup that will not interfere with other uses of the tags. HTML browsers are required to ignore tags and attributes that they do not understand or use." http://staff.plugged.net.au/dwood/xmlc/dynamic.html#sample_html So, xmlc seems to be an alternative solution to the original motivation behind embedding DTML within HTML Comment / Server Side Include style tags. The convention exists, so that's a way Zope can fit in to Zope-unaware HTML environments. "But using external fragments ("includes") is not a natural idea for web designers. One of the main points of this fuss is to allow them to create the templates in something like Dreamweaver." http://lists.zope.org/pipermail/zope-dev/2000-September/006899.html However, it's hard to imagine that Web "Designers" can survive the XML wave without becoming comfortable with inclusions. Doesn't the current version of Dreamweaver have "folding" capability to "collapse" inclusions, such as Javascript, and even entire tables, so only a pair of tags is displayed on the screen? No doubt this feature will quickly become a "must have" item, as fans of folding editors can attest. The verbosity of XML demands some solution, and the usability of "folding" is well proven. At that point the real question is, "If xmlc and DTML can both be easily included, collapsed, etc., what sort of power and flexibility might be lost with an xmlc-ish convention?" Re. changing Bad Habits "The current "header/footer" fragments are not optimal wrt. modularization, as tightly coupled stuff ("footer" must close everything that "header" opened) is separated into different objects." http://lists.zope.org/pipermail/zope-dev/2000-September/006907.html Certainly breaking well-formedness by placing HTML, HEAD, BODY, etc. in standard_html_header, and closing HTML, HEAD, BODY, in standard_html_footer was a dead end. But it's not at all difficult to package up as inclusions all the other pieces-parts, while keeping HEAD, BODY, etc. within a monolithic "wrapper". No doubt a multitude of other common DTML sins can likewise be mended with diligent well-formedness. "Of course you can already use "includes" which are valid XML, such as a single row or cell of a table (for example, the navbar of a complex site)." http://lists.zope.org/pipermail/zope-dev/2000-September/006899.html The perceived "problem" with this approach is that the Designer sees "nothing" where these items will be inserted. Actually, in edit mode they can see a dtml-var tag. Yes, this can be confusing for Designers, but use of inclusions is not really new, nor isolated to Zope. Anticpating "the inclusion thing" will remain a persistent problem is based on the assumption that Designers won't "learn to love" inclusions, which seems unlikely. Re. kludging Zope to do "what they want" Ideally, Zope's native ftp server can deliver DTML inclusions, which DreamWeaver, et. al. can "cache" for display purposes. Can Zope's native ftp server be taught to recognize such requests, and respond with a reasonable (rendered) facsimile, even if some resources are not currently available? That should keep visually oriented folks happy, since they'll be able to see a mock-up, at least. If that's possible, the little gotcha of Dreamweaver wanting to write back after updating might be handled politely too? Meeting this need one way or another is the whole point of the "round trip", edit vs. rendered discussion. So much for speculation about how a hypothetical SuperZope might learn to recognize requests from an editing tool, as opposed to some other ftp client. I know, ftp is not a smart protocol . . . Re. anti-inclusions, HTML "dummies" "It is much better to have a module that contains both the page prolog and epilog and a placeholder for the actual content, maybe filled in with sample text that later is replaced by the content, i.e. a page template. It is good that you are forced to use well formed XML in your modules." http://lists.zope.org/pipermail/zope-dev/2000-September/006907.html How is the "place-holder HTML that will never be rendered" solution any more appropriate? Perhaps simply because it's possible, as opposed to the mythical ftp beast above? It seems less so to me, at first glance. If we're seriously concerned over Designer reactions to inclusions, what will they say when we tell, them, "Just put anything there, for now, the system will handle it?" If they can get used to "subtractions", what's the real problem with "inclusions"? Aren't collapsed tags Good Enough as placeholders? It's a "visual" thing? Of course, I don't have a clear notion of how the xmlc model will change the way methods are invoked, and the innate capacities of Zope to deliver flexible solutions in this context. I'm eagerly awaiting a few lucid example demonstrating that Zope+xmlc is not only cleaner, and better future proofed, but actually more powerful and flexible than ever. That would be an offer I couldn't refuse! Thanks for all the Goodies, Jerry S.