Lists Home |
Date Index |
- From: len bullard <firstname.lastname@example.org>
- To: David Megginson <email@example.com>
- Date: Tue, 14 Jul 1998 21:41:22 -0500
David Megginson wrote:
> Simon St.Laurent writes:
> > If and when there are XML editing tools that are any good - and my
> > pessimism comes from my rather miserable experiences with even the
> > latest HTML tools - this may be true. In the meantime, lots and
> > lots of experienced coders, the ones most likely to gravitate to
> > XML, are still going to be hand-coding.
> By far the best solution is for developers to keep their scripts out
> of line and point to them -- that lets each language (programming or
> markup) be represented using its natural syntax.
Yes. This <% "<TD> 'SELECT '&_ %> is a
syntax that will sell an editor particularly when spread
across concatenated statements on multiple lines.
> The advantages are quite significant:
> 1. Ease of authoring: you can create your script using tools
> customised for the script's language (such as an Emacs mode) --
> that way, you get syntax highlighting, paren matching, etc., and
> don't have to escape XML delimiters.
Yes. OTOH, my hope is XML editors are cheap enough to make that
having specialized editors for XML application types is common, so
the *dirty word coming - semantic* or symbolic representation in an icon
hides the markup at the edit level. Remember the final battle cry of
SGML authors: HIDE THE MARKUP from the typing-impaired.
> 2. Ease of management: since the script is outside of the XML/HTML
> document, is easy to create, store, test, and revision separately.
Question for the document object model gurus: what happens to the scope
order if function calls in event attributes are removed as well
as other post-form inline code? Right now we have include
statements with different syntaxes in both client and server
side scripts. I know it's a neat thing that we can mix VBScript
<![[CDATA ..]]> is beautiful.
> 3. Ease of analysis: someone else looking at your work can easily tell
> what is markup and what is code; you don't need an analyst who
> knows _both_ XML and the scripting language.
That is good separation of work functions. Those of us
who have to generally have to know both to create code of that
complexity. This brings back a good feature of early SGML
systems like the Mentor Context editor where the authors could
see markup if they wanted too, but otherwise never saw the
scripting. The script language did not mix in the SGML
constructs. However, in contrast to HTML, GUI scripting
was also separate. I think this is an interesting problem
for XML applications to solve since quite a lot of the
scripting in web pages supports the GUI. I understand
of course, that the IE event model opens up all objects
for events so <p onClick= is a legitimate and useful construct.
> 4. Modularity: since the script is self-contained, it is easy to
> replace it later without necessarily editing the original document.
Yes as long as the namespace relationships are easy to track for
the author of the code but again, no worse than include files.
> 5. Ease of Reuse: since the CSS, ECMAScript, or whatever stands alone,
> you can reuse the same script for many documents, and all documents
> will register changes instantly and automatically.
Yes. Include statements. More?
> The disadvantage is that management becomes difficult when there are
> dozens (or hundreds) of small code fragments rather than one large one
That is the web in general, so folks are used to it.
> -- that is why my advice does not yet apply to literate programming
> (at least, not until there's good tool support).
Or generalized literacy. :-)
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)