W3C home > Mailing lists > Public > w3c-sgml-wg@w3.org > February 1997

Re: What to do given both SYSTEM and PUBLIC?

From: Len Bullard <cbullard@hiwaay.net>
Date: Wed, 19 Feb 1997 16:29:42 -0600
Message-ID: <330B7ED6.2B92@hiwaay.net>
To: Peter Flynn <pflynn@curia.ucc.ie>
CC: w3c-sgml-wg@w3.org
Peter Flynn wrote:
> Paul Prescod writes:
> >Whereas the "Java world" as represented by Sun just chose a solution based
> >on readily available software (.zip with no compression) and got on with
> >it.  I would really like it if we could just choose a solution and "get
> >on with it." I don't care if it is as simple and inelegant as "tar" (in fact,
> >I would prefer a system that was as simple as tar).
> I agree, but the solution needs to be acceptable to authors and implementors.

Hmm.  You could find some and ask them.  Of course, the love of the ear 
is to hear what it heard before.  That question usually sets off the 
platform wars.  Gzip is popular because free, but not a great way to
pack up multiple files, so in reality, just compression.  Pkzip can 
pack multiple files and compress, but it's not free.  What Lee said 
should be considered:  fat packets piss off the NetLords.  Small, 
"guaranteed overnight deliveries" are the way of the web.

> If it doesn't make sense to them, it won't fly, and right now, the dingdong
> over PUB vs SYS comes out as a straight play between FPIs and URLs. I can
> guess which one NS and MS are going to pick. 

Don't let them pick.  Pick smart here.

Pick the one that can be implemented fastest in XML 1.0.
URLs are well-defined and can do the first set of jobs.
Public are what is needed for absolute independence.  Now, 
when is it often necessary to be independent at transfer?
When is it necessary in local storage?  When is it necessary 
when archiving?

> Sun did an excellent job on
> packaging, except picking the filetype ".zip" for something that conflicted
> majorly with the established practice (read: expected behavior), which was
> a really crass thing to do.

> Let's not make the same mistake.

You mean there is another mistake we can make?

Received on Wednesday, 19 February 1997 17:41:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:25:07 UTC