[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

About templates

  • From: "Didier PH Martin" <martind@n...>
  • To: "'XML Dev'" <xml-dev@i...>
  • Date: Thu, 18 Nov 1999 17:02:55 -0500

trafic jam
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!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.