Cart
[Home] [By Thread] [By Date] [Recent Entries]
Robert La Quey wrote: > The basic problem remains a lack of a clearly articulated vision of what > the web of the future could/should be. Okay, Bob, let me take a crack at this. As will no doubt be obvious to anyone who has read my last few posts, I am quite sceptical as to the real value of RDF. My hope is that XML schemas will come to be viewed as the right mechanism for specifying object-oriented structures, turning XML instances into object serializations with all this implies. I said some nasty things about RDF in my "Pleas for Schemas" (www.praxisxml.com/praxis_xml.html) and was frankly quite disappointed that no RDF proponants stepped up to defend their case. The current discussion in this context is therefore very interesting and edifying for me. Anyway, my personal vision for the "new" (i.e. XML-enhanced) Web is quite simple. Let's look at the pieces one by one: * Namespaces -- are there to specify unique names. No more, no less. They should be orthogonal to schemas, so a single schema can use several namespaces and vice versa. The choice of URIs to uniquely scope names is clever and elegant, but there needs to be a specification of what is at the end of the URI. Apparently people get really confused otherwise. Something like Simon St. Laurent's XPDL would be a great choice, but oriented towards namespaces and not schemas and pointing to further resources that might be of interest (such as schemas that use the namespace and human-readable documentation). * XML -- is for representing tree structures in text format. * XML schemas -- are for turning XML instances into objects, adding information about the semantic relationships between element types. They are also repositories for business logic related these element types. I strongly contest the view that business logic can only be represented in a messy combination of human-readable documentation and running code. Schemas can provide a huge amount of semantic information in various ways: - Semantics of element type relationships (e.g. one element type is an attribute of another, and not just contained in it) - Plausibility constraints (e.g. allowed data ranges or regexs for string; this is already is the spec) - XPath constraints. I think Rick Jelliffe's Schematron is a brilliant idea that would bring heaps of benefits when embedded inside an XML schema. Many types of nontrivial semantics can be expressed using XPath and linked directly to a given element type. - Opt-outs, for example links to Java classes that do further processing that cannot be expressed descriptively. At this point we have "lost" in terms of representing full application semantics inside a schema, but at least we have a central location for binding logic in a descriptive way to the applications data structures. * Stylesheets -- transform XML documents or render them in various human-readable formats. In this view, schemas provide the application logic to let XML actually do something. Websites become aggregators of XML documents (many of which will be generated dynamically from database content), the schemas tell the processing application (which might be on the server or on the client) what to do with the document. For example, I could write a servlet that, based on an arbitrary XML schema, turns an XML document into an abstract form definition (also XML) that can be processed by a generic "form" stylesheet and turned into an HTML form, a WAP form or whatever. This means I can turn any schema into an input form instantly with no programming whatsoever (and this works just as well for reports, query forms and what-have-you). So what we have are a bunch of objects in the form of XML documents zipping around the Web. Some are rendered for human viewing, some are consumed by other applications. Schemas are the glue that ties this altogether, doing two things: 1) Providing object and application semantics to the XML instances and 2) Serving as the unit for distributing, reusing and extending these semantics. I'd be interested to hear how the RDFers see things in relation to this vision. I know it's a little half-baked, but I don't want to write a 20-page mail and I'm sure no one wants to read it. I am working on something more detailed to be posted on our website; we have tons of ideas and plans in this direction. Cheers, Matthew 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/ and on CD-ROM/ISBN 981-02-3594-1 To unsubscribe, mailto:majordomo@i... the following message; unsubscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
