Alternatives to the W3C
cbullard at hiwaay.net
Thu Jan 20 04:29:44 GMT 2000
Len Bullard wrote:
> Dave Winer wrote:
> > >>It makes sense. We aren't quibbling that a web browser of some kind is
> > needed, but is it TheWebBrowser (ie, the XHTML centric one), or just a
> > content handler that knows HTTP and has an API for scripting?
> > We've had this discussion at length on my site, and reached a conclusion.
> > There are two types of developers in the world:
> > 1. Web developers, who must look at the content exactly as their users look
> > at it. For these people, today, that's MSIE 5.x on Windows, not any content
> > handler, that specific one.
> > 2. Everyone else.
"You and me against the world, it looks like you and me against the
It's an old song, Dave. If the web is some engineering singularity,
what characteristic is the coupled driver that separates it from
all others? The Web is not a force of nature. It is code.
> > I could try to explain why this is so, but previous debates make me
> > reluctant to try, so I won't.
I will. Reliability. You are version bound for the
same reason the proprietary system gets good reliability numbers: a
single codebase under version control and compiled by configurable
processes but predictable processes. You use a named component.
Important. It is named for the codebase; not the spec.
> > Think of it this way. You and I are developing
> > for different platforms. You like what you do, I like what I do. Life is
> > great.
And will get better. I don't just develop offTheWeb. My job is to
merge them and I think it is for most people here who work on content
and code. Our problem is not XML. XML is fine. Our problem is XML,
and DHTML, and X3D, and SVG and so on. Seamless interoperation must
equate to behavioral fidelity over some predictable time or certain
kinds of content cost too much: TV has to work every time you turn it
on. You can't be buying a new tuner every week. If the TV is that
maintenance intensive, it had better maintain itself.
If I were GatesTheSoftwareEng, I would ask myself the question the
developer community asks? How can we get the reliability numbers for
components up? So far, the solution is always tied to the named
codebase. IDLs don't seem to say enough about behavior to assign
A spec, something an FPI names, is not the code. The component named
by the namespace (eg, consider how SAX sets characteristics with
namespaces) must have a logistics value. The dilemma is what is to be
to make that available, and how to use that dynamically to determine
components possible. Do that in real time.
Behavioral fidelity expressed as reliability. IOW, as good as TV.
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ or CD-ROM/ISBN 981-02-3594-1
Please note: New list subscriptions now closed in preparation for transfer to OASIS.
More information about the Xml-dev