OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help




[ Lists Home | Date Index | Thread Index ]
  • From: len bullard <cbullard@hiwaay.net>
  • To: xml-dev@ic.ac.uk
  • Date: Thu, 16 Jul 1998 18:45:28 -0500

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.


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)

  • References:


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS