Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: It's time for practical XML!
 At 23:27 03/10/98 +1000, James Robertson wrote: >Hi all, > >I've just finished another couple of hours >wading through XML-DEV and XML-L, and I >confess my frustration has overtaken me. I understand this. I have been trying to develop this list as somewhere where things actually happen. We've had some success. But the successes rest on a great deal of *necessary* discussion. For example, in the discussion of how we build objects from elements it is clear that there is lightly explored territory with some very good contributions. There are different ways of doing things and some may be preferable to others - this will only emerge after the discussion. The history of SAX is an example. There were about 2 early forays into this field, which revealed it was important to do something and laid some groundwork. They then went fallow (a positive word) and finally David Megginson conducted XML-DEV during Dec 1997. It looked like it would take a month - and the first part did. But then there was the hard graft over ca. 3 more months while the details were ironed out. I would contend that the process per see could not be easily bettered. The same thing has happened - over a more gradual timescale with XSchema. Something is clearly needed in this area - whether XSchema is 'it', only time will tell. At present it looks like being the first offering in this field and over 50 people (I think) have contributed to the discussion. There is clearly a very great need for something similar for objects/elements. We are at an early concept stage. There are many different views of the way that elements might be transformed into objects. For many applications (e.g. technical, non-textual) this is *the* most powerful and critical part of XML. For example MathML and CML will rely on structured objects if there is to be re-use (rather than rendering) and we cannot proceed confidently until it's solved. > [...] > >It's time to stop writing standards. >I don't want to know about any more >*ML languages, however elegant they >are. We are now at the stage where >new standards are being submitted >faster than old ones are being finalised. I think we should distinguish between extensions to the functionality of XML and markup languages based on XML. The extensions to the functionality are horizontal such as XLink, XPointer, RDF, DCD/XSchema, XSL, etc. They may be a fundamental part of new markup languages. For example, my own contributions - CML and the Virtual HyperGlossary both rely on XLink to provide powerful data structure. *My* frustration is the XLink (and XPointer) are still not Recommendations. And I cannot expect people to build robust commercial tools until these specs are dry. > >Now I know it is a lot more fun to >talk about the next gee-wiz solutions >to the world's problems, but we all >need to get stuck into some hard work. I agree. I sometimes think that the discussion on XML-DEV is too far removed from implementation, but I haven't intervened. Many of the contributors also help create tools, demos, resources, etc. For example, the discussion on names may seem abstract, but people like Eliot Kimber have contributed greatly with implementations as well (e.g. PHyLIS - if have the caps right). Most of the regulars on this list work very hard at collaborative contributions - it may not always show above the surface. > >A lot of people seem to be trying to >hit every target with XML, and most are >talking about "finding the killer app". > >XML does not need a killer app. It is >not a solution unto itself. It is a >handy tool for doing real-world work. > >I have not participated in these discussions >on the whole, because I have been too busy >implmeneting SGML in the workplace, using >standard languages and off-the-shelf tools. Fine :-) and I hope you will implement XML when the tools are available for your purposes. Part of this list's traffic is coordinating the development of those tools. SGML had a lack of cheap tools and there was often little interoperability. So it led to good in-house solutions but poor WWW provision. XML is designed to be used over the wire and aspects of that are hard. As someone who has written some of the tools, even getting them distributed easily isn't easy. And interoperability is impossible without public discussion. > >I want to be able to do the same with XML. > >What we all need is: > >* rock-solid XML parsers for every platform > under the sun, especially business development > tools like: Visual Basic, Delphi, Powerbuilder, > etc. We have rock-solid parsers. We have a rock solid event-based API (SAX) and we have a rock-solid Object model (DOM). We desperately need the next layer on top of the DOM for may *ML applications. >* Embedded XML editors for use in business-specific > applications. These need to be ActiveX controls, > Delphi VCLs and the like. XML editors are *hard*. They require substantial investment. If they are to be syntactically (DTD) and semantically (Schema) driven we must have agreement on those. That's why XSchema and related efforts are so important. For example, I have written a forms-based editor for JUMBO. Works. *But* it is based on my own data types. It *has* to be, because no-one agrees on how to send a floating point number using XML. We shall, sometime. I'm frustrated by the lack of specs here :-) > >* Thousands of handy little tools that run without > virtual machines, or other overhead, with simple > interfaces, that make handling XML easy. They will not interoperate unless we have standards. Can I create an XML document with software X and send it to someone with software Y? Only if we agree on what is to be sent. There are a number of ways of agreeing: - everyone buys their toolkit from a single vendor. This can work, but it doesn't encourage innovation - a small number of toolkits evolve independently. This tends to lead to islands of interoperability. But it's awful for me. Let us assume that Netscape and MSIE expose different object models. Then to send a molecule from X to Y I have to write CML software for *each* browser. And when coins/XXX/SUN/XML4J all expose different interfaces the chemical community has the same babel as it has now (except that that is based on Fortran). Also semi-closed interfaces like this make it very difficult to develop semantic interoperability. - we discuss the problem openly and converge towards solutions where possible. XML is a prime example of this. There *was* a starting point (SGML) and it took 100+ people + many more contributors 1.5 years and 10000 e-mails to get to the current Rec. Namespaces took 2000 e-mails. We are attempting something that has never been done before - the creation of objects on one machine that must be semantically interoperable on another machine (after transmission in serialised form). The two clients have had no previous negotiation. [That, in part, is a reason why the name debate is so passionate and runs and runs - we have very little global experience of identifying machine-readable objects by universal names other than *.html documents]. > >Most of these solutions need to be commercial, >with support, documentation, upgrade plans, >bug-fix releases. Business will not use unsupported >freeware, and they _will_ pay for the tools they >need. I won't challenge this - even though I am an OpenSource fan and think that the Linux model is extensible to XML. [And many contributions on this list are top-quality OpenSource with no evidence that they are unsupportable.] My prediction is that over the next 2-3 months we shall see lots of first version XML tools from vendors - many, but not all, with SGML backgrounds. I suspect that there will be little effective interoperability between these tools except at syntactic level - they will emit WF XML, but beyond that they will give little support for managing documents produced by others. Maybe this is a necessary phase. I hope we can move past it. I am still in favour of a diversity of suppliers and applications but I hope we can work towards having semantic interoperability > >There are a lot of _exceedingly_ good developers >on this list. > >To them I say: Please, please, stop writing new >specs, and help us all by writing real apps. I think a lot *are* writing apps. I think also, that they desperately need specs to write these apps. My own experience is that I can develop something about 5 times faster if I have a spec to work to rather than working it out for myself. In the latter case there is: - the worry that you aren't going in the right direction - no one to turn to for help - no interoperability. etc. So when XLink, XSchema, XPointer, SOAPI (or whatever we call it) are frozen, people will develop apps much more rapidly. BTW - if you would like to help speed the process up we would be delighted :-) P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...) 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
