Lists Home |
Date Index |
- From: len bullard <firstname.lastname@example.org>
- To: email@example.com
- 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
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: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)