Alternatives to the W3C

[Len Bullard]

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
 world."
 
 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.
 
 Sniffer scripts??????
 
 If I were GatesTheSoftwareEng, I would ask myself the question the
content
 developer community asks?  How can we get the reliability numbers for
the
 components up?   So far, the solution is always tied to the named
 codebase.  IDLs don't seem to say enough about behavior to assign
numbers like
 MTBF.
 
 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
tested, how 
 to make that available, and how to use that dynamically to determine
the best 
 components possible.  Do that in real time.
 
 Behavioral fidelity expressed as reliability.  IOW, as good as TV.  
 
 len


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.