xml-dev - About templates

["Didier PH Martin" <martind@netfolder.com>]

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@netfolder.com
http://www.netfolder.com


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)