[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: <XML:SCRIPT>

  • From: len bullard <cbullard@h...>
  • To: xml-dev@i...
  • Date: Thu, 16 Jul 1998 18:45:28 -0500

impromptu script
Simon St.Laurent wrote:
> 
> DM> > The disadvantage is that management becomes difficult when there are
> DM> > dozens (or hundreds) of small code fragments rather than one large one
> >
> LB>> That is the web in general, so folks are used to it.
> >
> SC>People are becoming more and more aware of the enormous cost involved,
> SC>however. Saying Web folks are just "used to it" is adding to an already
> SC>ridiculous burden.
> 
> I agree with Steven Champeon - let's not get into the habit of allowing costly
> management strategies just because they're already employed in the impromptu
> world of HTML or the more (and less) structured world of SGML. 
> Until then, I'd rather not see them shrugged off.

We neither allow or deny.  We propose and implement.  If the burden is 
ridiculous, it is still borne daily.

If I was shrugging it off, you might be right.  However, in short form, 
I am noting the situation as is.  Modularity is a highly prized goal in 
any programming or documentation tool.  That usually means "lots of 
little files".  The advantages are obvious and practical.  From the 
inception of the web design (eg, transmitting information inside 
URL strings and headers (get/post)), keeping file sizes small has 
been a design goal.  Otherwise, wav files would be more practical than 
they are.  Bandwidth remains the most pressing problem for complex 
web applications.

It is the management of the namespace with regards to the scripts that 
is of interest.  Not inlining scripts has disadvantages as well. 
The more pressing issue is how XML systems interact with non-XML 
systems using the same set of scripting languages.  Enterprise 
integration committees hit this problem head on eventually.

However much one chooses to complain or criticize, the current 
browser models and the languages they support are being used 
to create both transaction-bound and viewing applications.  These 
are tough to build.  If XML concepts can make this easier, 
que bueno.  If not, next.  We need to know what the W3C has 
in mind for scripts on the client and server sides.  I know 
its a tough problem having worked with groups that tried 
to solve it.  Complete separation of script and content is a 
worthy goal, but a tough design.  Best of luck to all who 
are working on it.

len

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


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.