Regulating the XML Marketplace

Fri Jan 8 15:10:20 GMT 1999

I agree that XML makes things lot simpler and cleaner than any other
proprietary data exchange format.

The biggest hurdle, I see for XML apps to pick up is uniform,inbuild XML
Parsing (XDK) support across popular browsers.
The present problem is to select one of the available XML parsers, make
sure it works on the popular 
browsers and also the XML Parser jar file has to be served by the server
which is a problem in 
particularly embedded systems environment.

Shekhar Kshirsagar
Nortel Networks.

At 04:00 PM 1/7/99 -0800, you wrote:
>I partly agree, and partly disagree. Yes, XML needs a person and/or
organization to guide its evolution. But I don't think it needs a killer
app. Lots of cool stuff is already being done with XML. The analogy with
Java is a good one. You have the language, then you have the JDK on top of
the language. While the language has been completely stable, the JDK has
gone through a somewhat painful evolution process from 1.0 to 1.1 to 2.
Similary, the basic XML 1.0 spec is just fine (IMHO). It's the XDK, if you
will, that needs help (again, IMHO). And, as I've said before on this
mailing list, it's the XDK that lets people do meaningful work.
>
>Jeff
>
>-----Original Message-----
>From: owner-xml-dev at ic.ac.uk [mailto:owner-xml-dev at ic.ac.uk]On Behalf Of
>Rob Schoening
>Sent: Thursday, January 07, 1999 3:48 PM
>To: Simon St.Laurent; XML-Dev Mailing list
>Subject: RE: Regulating the XML Marketplace
>
>
>Hi-
>
>Simon makes a lot of good points.
>
>I'm afraid that what we're seeing with XML is what Java would be without Sun
>or Linux would be without Linus.  No one has yet emerged as the XML
>evangelist.  I don't mean to take anything away from the people (on this
>list) that have helped make XML what it is.  However, I don't think that
>there is going to be much cohesion among standards until someone like
>McNealy or Linus steps up and takes the stand.
>
>I believe that this is due, in part, to the fact that XML applications are
>still fairly esoteric.  There is no "poster-child" application for XML.
>The popularization of the applet in 1996 was a huge step for Sun.  The
>applets were totally inane, but that was beside the point.  The applets
>attracted eyeballs.  The minds and ears followed.
>
>Someone needs to come up with something clever with XML.  It sounds
>difficult and improbable.  But how many people who wrote virtual machines in
>college would have believed that the same essential technology would make
>people excited to play TIC TAC TOE?!  A virual machine is no more or less
>esoteric than XML.
>
>Who is going to make it happen?
>
>Rob
>
>> -----Original Message-----
>> From: owner-xml-dev at ic.ac.uk [mailto:owner-xml-dev at ic.ac.uk]On Behalf Of
>> Simon St.Laurent
>> Sent: Thursday, January 07, 1999 7:29 AM
>> To: XML-Dev Mailing list
>> Subject: Re: Regulating the XML Marketplace
>>
>>
>> At 09:42 AM 1/6/99 -0500, you wrote:
>> >Simon St.Laurent writes:
>> >
>> > [about the highly secretive, smoke-filled XML Coordination group, aka
>> >  The Syndicate]
>> >
>> > > I'd love to see a set of goals from the higher level group like the
>> > > working groups below it have so successfully produced.  Right now,
>> > > the emperor himself is pretty invisible to the outside world.
>> > > There's no broad statement of what the XML family of standards
>> > > should look like when it reaches maturity (or puberty, even.)  I
>> > > think everyone on this list has their own, usually incompatible,
>> > > vision of what XML should look like.  A statement of what it will
>> > > look like might give us something better to work with, introducing
>> > > less complication in the long run.
>> >
>> >Actually, the problem is a little different.  We all know what XML
>> >looks like -- it's described pretty clearly (modulo a few errata) in
>> >the XML 1.0 spec [1].  What we're waiting to find out is what
>> >applications that happen to use XML will look like.
>> >
>> >Somewhere out there, there's a yet-to-be-discovered magic dividing
>> >line between what the W3C should and shouldn't regulate -- clearly,
>> >core XML 1.0 syntax falls on the W3C side of the dividing line, and
>> >just as clearly, the source code for a specific XML parser falls on
>> >the other side.
>>
>> The problem that I'm describing isn't about where that dividing line is -
>> the W3C seems to have decided that reasonably well enough for itself,
>> though that's always contestable as well.  The problem is that the W3C
>> doesn't appear (to those of us outside the smoke-filled room) to be taking
>> any initiative in regulating how its standards interact with each
>> _other_.
>>
>> XML 1.0 is at least the foundation, though namespaces cause problems with
>> much XML processing, as has been described repeatedly for the last 24
>> hours.  Beyond that, however, it's not at all clear how XLink and XSL
>> relate to each other, how transformation relates to validation, either
>> traditional XML or using a schema, how XPointers and query languages will
>> be similar or different, and why, and how to best deal with the
>> 'incoherence' of the multiple specs - XML's usage of entities and
>> notations, XLink's relationships of resources, and the xml-stylesheet PI's
>> blunt grabbing of a URL-based resource with MIME type specified in the PI.
>>
>> This is a pretty ugly mess, and explaining it requires a lot of throwing
>> your hands in the air and saying "that's the way it is".  It may
>> mean a lot
>> more work for the W3C to clean it up, but it'll make for a far better
>> standard in the long run.
>>
>> >Beyond obvious cases, though, we have the classic problem of how to
>> >regulate a market without killing it.  We could take the Old
>> >Labour/New Deal approach and nationalise everything, we could take the
>> >Margaret Thatcher approach and privatise everything, or we could try
>> >to be Tony Blairs and please/disappoint everyone a little without
>> >taking any firm positions.
>>
>> On the interactions between the specs, the W3C is definitely Tony
>> Blair.  I
>> don't think it works as well in technology as in 'real-world'
>> politics, but
>> others may have different views.
>>
>> Also, remember the W3C is barely a 'regulator' by its own terms -
>> specs are
>> just 'recommendations'.  I'd love to see a stronger W3C, but a much more
>> open one, but I can't say I expect to see that.
>>
>> Simon St.Laurent
>> XML: A Primer / Cookies
>> Sharing Bandwidth
>> Building XML Applications (February)
>> http://www.simonstl.com
>>
>> 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/
>> To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
>> (un)subscribe xml-dev
>> To subscribe to the digests, mailto:majordomo at ic.ac.uk the
>> following message;
>> subscribe xml-dev-digest
>> List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)
>>
>>
>
>
>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/
>To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
>(un)subscribe xml-dev
>To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
>subscribe xml-dev-digest
>List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)
>
>
>
>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/
>To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
>(un)subscribe xml-dev
>To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
>subscribe xml-dev-digest
>List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)
>
>

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/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)