Hi, After some months of silence, several hundred miles with my bike in China, writing about XML for Wrox, I am now back to work on new things. Recently, I made an interesting discovery. I tried to simulate a world full of XML browsers and what would be the implications of such world. a) The whole notion of XML server may change. Different XML document providers or should I say XML fragment providers will emerge. Among them: 1) relational data base accessible with URLs, HTTP and datasets returned as XML documents. Directory services (same scenario), e-commerce services, etc... In fact, in the following month we'll see a plethora of new XML servers appearing on the market. We already have technological previews from Oracle and Microsoft's for their respective RDBMS. b) The notion of XML fragment is becoming more and more important. A request to an XML server may not necessarily mean that the result should be a complete XML document but more a fragment to be included in a template. c) The notion of an XML template will become more important than ever. The template provides a framework for document assembly. In this template we specify which fragment we want. For example, a template may request XML fragments from a LDAP server and a fragment from a relational database. The actual notion of template we currently have (through style sheets) is that the result tree source is an XML document. This may not be the case for most e-commerce applications where fragments have to come from other sources. In an XML template, like it is now for an XSL templates, some elements are replaced by XML fragment coming from XML servers (like for instance a relational DB). d) Finally the document assembled from fragments is sent to the browser and rendered with a style sheet. So, what we have now to think more of is: 1) XML document fragments 2) XML templates. The format may be the same as the XSL simplified format - or XSLT could be extended to support document assembly from XML servers. This implies that new elements have to be defined like for example database SQL request. Actually, Microsoft uses their own sql name space (i.e. <sql:query> ) and Oracle their own implicit one (i.e. <QUERY> ). Idem for directory services DSML lead by a NH startup. Do we extend XSLT to include these new constructs? So, XSLT would no longer be for XS Transformations but more for XS Templates :-) 3) The returned elements in the case of RDB and directory services would benefit greatly to follow the RDF format. IN this case RDF wouldn't be solely limited to meta data (yes I agree with you on this David :-) Suggestion: for a RDB row we would have: <rdf:description about="urn:<DB>:<table>:<key>"> ....fields here.... </rdf:description> for a directory service: <rdf:description about="ldap://ldap.itd.umich.edu/c=us"> ...ldap fields here.... </rdf:description> the problem though, could be with rendition if all fragment elements are rdf elements. This could be prevented by the fragment type or the enclosing element. For instance a RDB may return elements of type <database> and directory services of type <directoryservice> then a style sheet can be set to the proper context. Like Paul Valery said at the beginning of the century said: Act like a man of reflection and think like a man of action. I am writing a document about these issues on a more elaborate format and will submit it to you for comments. Until then, do others share the same interest for a common solution for a piece of the semantic net? PS: about SML my answer is why not? let's pursue this and see what can come out of this. Let's see the process as a kind of stepwise refinement from the complex to the simple. This is a journey ususally not done in a single step since we have to deal with the inertia of history :-). And after all, a different point of view may worth a thousand point of IQ, so let's try and see... Duane, during my trip, this was the first time in my life that I saw a bike trafic jam. You know what, it is as worse as a car trafic jam :-) Cheers Didier PH Martin mailto:martind@n... http://www.netfolder.com 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...)
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