xml-dev - Re: <XML:SCRIPT>

[len bullard <cbullard@hiwaay.net>]

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
and execution 
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 
and JavaScript in a page, but wow, if that is OK then  
<![[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.  :-)

len

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)