Jim Fulton wrote:
Some tools, such as Netscape Composer provide minimal support. You can actually select and edit DTML tags. In fact, DTML tags get as much support as FORM tags.
Ironically, Composer doesn't do form tags. :^)
It would be helpful to make hideuosness a little more specific.
Good point.
What makes it hideous? Is it the noice characters? (!--#) Is it the number of shift characters? Is it the fact that DTML don't look like other tags? Is it the tag in an attribute problem mentioned above?
I'd say, in order: 1) It doesn't look like the competition. (which is largely <% or inventing their own tags). 2) Excessive noise. 3) When something interesting requires the expr machinery, you can only do one expression per line. (Note that this complaint isn't slated to be solved by a syntax change in DTML, just that it is a common complaint).
Tool Support ------------
The SSI syntax just happens to enjoy nearly zero support out there. Things like Netscape Composer, Dreamweaver, and Emacs HTML Mode just can't be convinced to handle it nicely.
Does anyone view this issue as important?
Yes. What would be needed to make HTML (not XML) editors happier?
This is the crux of the matter. It will be a LONNGGG time before XML editors saturate the market. Thus, we have two problems: a. Better syntax that is friendly to HTML authors and HTML editing tools. b. Different approach focused on future standards and tools (XML). This discussion is rightfully being geared back towards (a). Here's a chance for all of you folks out there with expertise in HTML tools (Dreamweaver, FrontPage, Cyberstudio, Alpha, Emacs, etc.) to weigh in.
2) Becoming well-formed means the authors can be given hints before saving changes,
Good point.
Jeffrey gave Jim and me a demo yesterday of how, with the syntax changed to <dtml-in>, the Alpha editor could be taught all the options for the in tag and present checkboxes.
and Zope can do smarter things with structured data on the server.
I'm not so sure about this one. Zope has alot of structured data now. For example, it would be pretty easy to find the var references in a parsed DTML object, but I'm not sure how much that gains you.
Let's say you rename a document. Nearly all the competition will update all the references to the document.
3) Zope syntax might not be mappable into XML.
This isn't a problem.
It was a problem for my XHTML proposal. It isn't a problem for goal (a) described above.
Here are some more why nots:
4) XML is wildly more verbose that HTML and, without tool support, people might find an XML variant of DTML or HTML to be a real pain.
I think we should rush blindly into implementing standards, as I proposed, then when everybody hates *that* as well, we come up with something sane. :^)
5) DTML is used to generate a variety of text output. While it *is* used mostly to generate HTML, it is used to produce a variety of other formats as well.
At any rate, I think that an XML variant of (or cousin of) DTML would be a great idea. I expect that DC will do this eventually, if no one else does. I'd expect am XML version of DTML to be able to work with any sort of XML data, including XHTML.
I don't think, however, a plan to have an XML variant of DTML should prevent us from improving the non-XML version.
Well stated. --Paul