XML and keeping things seperated?

[Stan R.]

One more question if I may. From what I've gathered, usually you include
the XSLT template right into your main xml doc you're working with,
like:

<?xml version="1.0" encoding="ISO-8859-1"?>
<?xml-stylesheet type="text/xsl" href="test.xsl"?>


My question is, is it possible to have the main xml doc in one file
(say, main.xml), but have a seperate xml file for the transformations
(include both a XSLT and the main.xml document.)

From everything I've found online thus far, it seem including xml files
in other xml files isn't a very clear topic, but it seems to me it
should be an essential part if you want to keep things seperate and
organized, unless I'm really missing something here.

Maybe it's just the way I'm used to doing things when programming and
such, but it seems perfectly logical to want to keep the actual xml data
in one place, and have style-related stuff take place outside it, so it
can be styled in multiple fashions, for multiple purposes, like, for
example, have one XLST style sheet for html output, and another for
plain text, and maybe another for man or pod (shell) output. And not
just output, as XSLT can be used to transform into other types of xml
documents, as well as other forms of documents altogether.

Am I correct in surmising that the xslt, in the way it seems to be
normally included in the main xml file you're working with, seems to
have taken this aspect on fro mthe likes of HTML, which normally inlcude
CSS (either externally or inline) in the html file you're working with?
Because for the sheer power XML seems to hold, this doesn't look like
best approuch imho.

Is there a reason they didn't go with a more normalized approuch; that
is, you have your xml source in one file, different stylesheets in other
files, and a 3rd tier files that actually include/use both the xml
source i nquestion, and the stylesheet.

In other words, a structure like the following:

mydata.xml

mydata_style_html.xsl
mydata_style_text.xsl
mydata_style_rss.xsl
mydata_style_foo.xsl
mydata_style_bar.xsl

mydata_output_html.xml
mydata_output_text.xml
mydata_output_rss.xml
mydata_output_foo.xml
mydata_output_bar.xml

In this setup, you have your source in one file, and your style sheets,
each one specifying a different way of display the source data in
mydata.xml.

While it seems to me that while you would be able to, in the "output"
xml files, be able to include a style sheet (ie: <?xml-stylesheet
type="text/xsl" href="mydata_style_html.xsl"?> ), I don't see a way to
include another xml file in a similar way.

What I'm really looking for is something like this, in, say,
`mydata_output_html.xml` :

<?xml version="1.0" encoding="ISO-8859-1"?>
<?xml-include type="text/xml" href="mydata.xml"?> <!-- <--- (example
only) -->
<?xml-stylesheet type="text/xsl" href="mydata_style_html.xsl"?>

Where that is the only contents of the output file.

Thanks for any insight on this, I'm extreamly curious

 

[Andy Dingley]

One more question if I may. From what I've gathered, usually you include
the XSLT template right into your main xml doc you're working with,
like:

<?xml version="1.0" encoding="ISO-8859-1"?>
<?xml-stylesheet type="text/xsl" href="test.xsl"?>
Yes.

My question is, is it possible to have the main xml doc in one file
(say, main.xml), but have a seperate xml file for the transformations
(include both a XSLT and the main.xml document.)

Sort of, but not really how you're thinking.

XML "doesn't do" includes. There are various techniques applicable, but
they're either not workable, not implemented, or just not commonly
used. It's also relatively rare to use the <?xml-stylesheet ... ?> PI.
Most XSLT gets transformed on servers (for widespread output device
compatibility) rather than getting shipped out as XML with a linked
stylesheet and transformed on the final device.

So the linkage of content and presentation stylesheet is (in general)
done by external non-XSLT scripts calling XSLT engines from outside. If
you want to describe this linkage in an XML format then of course you
can do so, but most ways of doing it are project-specific and don't use
a clearly defined or standardisaed format. You can of course use the
PI attached to the document and read this from your script, then use
that to indicate the XSLT transform to use.

You might also find a look at the XInclude protocol and the Cocoon
project to be useful.

 

[Joe Kesselman]

My question is, is it possible to have the main xml doc in one file
(say, main.xml), but have a seperate xml file for the transformations
(include both a XSLT and the main.xml document.)

The example you've shown does exactly that -- the XSLT stylesheet is in
a separate file called test.xsl. (Most likely in the same directory on
the server, since this is a relative URI reference.)

If you want to _specify_ these independently, rather than having the XML
hint which XSLT to use, that can be done too... if your tools support
it. Certainly an explicitly invoked XSLT system can run any stylesheet
against any document. Theoretically, a browser could offer you that same
option of overriding the hint, or could allow a document to specify
several such hints and provide a mechinism allowing the user to pick
among them... but that's a matter of browser features and isn't well
standardized yet.

Welcome to the leading edge. <sigh/>

 

[Stan R.]

Sort of, but not really how you're thinking.

XML "doesn't do" includes. There are various techniques applicable,
but they're either not workable, not implemented, or just not commonly
used. It's also relatively rare to use the <?xml-stylesheet ... ?> PI.
Most XSLT gets transformed on servers (for widespread output device
compatibility) rather than getting shipped out as XML with a linked
stylesheet and transformed on the final device.

I wasn't really aware of that, thanks.

So the linkage of content and presentation stylesheet is (in general)
done by external non-XSLT scripts calling XSLT engines from outside.

Are there any common engines, for XSLT, as well as XML checking and
parsing, that are common on linux/UNIX and even win32 ? I think this
part is what really hasn't been clear to me. I am a seasoned programmer,
but xml is something I've very recently started exploring, so I guess
I'm just seeking advise from those in the know, and so far it's helped a
lot

If you want to describe this linkage in an XML format then of course
you can do so, but most ways of doing it are project-specific and
don't use a clearly defined or standardisaed format. You can of
course use the PI attached to the document and read this from your
script, then use that to indicate the XSLT transform to use.

Well if I knew about the engines that can handle the transofrmations
externally, I probably wouldn't of even asked my question, but again,
I'm just exploring something new.

You might also find a look at the XInclude protocol and the Cocoon
project to be useful.

Perhaps, thouhg other posts seem to indicate that is something not
widely supported yet, but may I assume that is something that will be
added to most major parsers, that do not support it, in the near future?

 

[Joe Kesselman]

Are there any common engines, for XSLT, as well as XML checking and
parsing, that are common on linux/UNIX and even win32 ?

I've been involved in Apache Xerces for parsing/validating, and Apache
Xalan for XSLT processing, so I'm biased in those directions. (Actually,
I'm working on a next-generation XSLT processor, but it isn't yet ready
for the general public.)

 

[Stan R.]

I've been involved in Apache Xerces for parsing/validating, and Apache
Xalan for XSLT processing, so I'm biased in those directions.
(Actually, I'm working on a next-generation XSLT processor, but it
isn't yet ready for the general public.)

Can those also be used from the command line?

 

[Joe Kesselman]

Can those also be used from the command line?

Xalan does have a command-line driver, though it can also be invoked via
an API.

Xerces... well, y'know, parsers are generally used because you want to
read the data into an application rather than because you want to just
parse it and throw it away again. But Xerces does come with a couple of
minimal sample applications that can be run from the command line, and
of course it can be used to implement apps that run from the command line.