including one XML file in another XML file

[Johan]

How can I include one XML file into another XML file (on the client
side, in Firefox)?

I think XInclude is just what I need, but Firefox doesn't support it:
https://bugzilla.mozilla.org/show_bug.cgi?id=201754

It seems I also can use an "external entity reference", but that
depends on a DTD and I'm using XML Schema. Is it also possible with a
Schema and how can I do it?

Here is exactly what I'm trying to do:

design.xml:
<?xml .....>
<root>
<design>....</design>
<library>.... </library>
</root>

Currently the 'library' element is inside the 'design.xml' file. I
want to put the library element into a separate xml file and include
it in all my design files. (I have a lot of designs and only a couple
of libraries).

The design.xml file contains a reference to an XSLT file that
visualizes the design. When you open the design.xml file in Firefox a
SVG (scalable vector graphics) file is created on the fly and shown to
you.

I also have an XML Schema file that specifies what all the valid
elements in the design.xml file are.

Can someone show me an example that accomplishes this? That would be
great.

thanks, Johan.

[p.lepin]

On Feb 21, 3:43 pm, "Johan" <joh...@gmail.c omwrote:

On 21 feb, 13:51, p.le...@ctncorp .com wrote:

On Feb 21, 2:14 pm, "Johan" <joh...@gmail.c omwrote:

On 21 feb, 11:30, p.le...@ctncorp .com wrote:
<xsl:styleshe et version="1.0"
xmlns:xsl="http ://www.w3.org/1999/XSL/Transform">
<xsl:variable
name="lib"
select=
"
document(concat ('xform_lib_',/root/@library,'.xml' ))
"/>
<xsl:template match="root">
<result>
<xsl:apply-templates/>
</result>
</xsl:template>
<xsl:template match="design">
<xsl:value-of
select="$lib/library/design[@n=current()]"/>
</xsl:template>
</xsl:stylesheet>

I will describe my problem in a little bit more
detail: The <libraryeleme nt contains one or more
<typeelements . Each type has an "id" attribute. The
author of the design.xml file can use type's from the
library by referring to their id.

Depending on exact way the author may 'use' the types
from the library, this might look similar to the
following:

<xsl:template match="refer-to-lib-type">
<xsl:apply-templates
select="$lib/library/type[@id=current()/@id]"/>
</xsl:template>

I don't have templates that match the library (or the
types inside it), so
<xsl:apply-templates
select="$lib/library/type[@id=current()/@id]"/>
isn't going to match anything.

Create the templates to match the library elements, then.
It's good design anyway.

I think the solution from fildpauz fits my needs the
best:

<xsl:template match="root">
<xsl:apply-templates select="design"/>
<xsl:apply-templates select="documen t(library.xml)/"/>
</xsl:template>

You don't seem to understand how this solution would work.
As you yourself said, you don't have any templates that
would match the elements within your library, so
apply-templates select="documen t('library.xml' )" would
merely apply the default templates to this nodeset.

The only question that remains is this one:
"How can I perform xsl:apply-templates to the union of
the design and the library together?

You cannot achieve the results identical to using XInclude,
period. You may attempt to do something like

<xsl:variable
name="everythin g" select="/|document('foo' )"/>

but even if it works for you, I doubt it would really solve
your problems. You seem to be way over your head as it is,
and if you try juggling nodesets without accidentally
converting them to rtfs and ending you days in an asylum
due to the sheer frustration of it, you're bound to drown.

(There aren't any templates that directly match elements
in the library. There template that matches the design
element gets values from the library when it needs them
(using <xsl:variable name="..." select="...">)) . "

So? I believe I explained to you how to write XPath
expressions accessing other documents, it doesn't matter
whether you use them to apply templates, grab values or
populate variables. Either you want to do it the easy way
(in that case, deal with it--there's no easy way short of
XSLT2, and no, existing browsers do not support that) or
you don't really understand what's going on (and in that
case perhaps you should stop tinkering with real projects
before you break something, and start tinkering with toy
projects).

--
Pavel Lepin

[Johan]

On 21 feb, 15:28, p.le...@ctncorp .com wrote:

On Feb 21, 3:43 pm, "Johan" <joh...@gmail.c omwrote:

On 21 feb, 13:51, p.le...@ctncorp .com wrote:

On Feb 21, 2:14 pm, "Johan" <joh...@gmail.c omwrote:
On 21 feb, 11:30, p.le...@ctncorp .com wrote:
<xsl:styleshe et version="1.0"
xmlns:xsl="http ://www.w3.org/1999/XSL/Transform">
<xsl:variable
name="lib"
select=
"
document(concat ('xform_lib_',/root/@library,'.xml' ))
"/>
<xsl:template match="root">
<result>
<xsl:apply-templates/>
</result>
</xsl:template>
<xsl:template match="design">
<xsl:value-of
select="$lib/library/design[@n=current()]"/>
</xsl:template>
</xsl:stylesheet>

I will describe my problem in a little bit more
detail: The <libraryeleme nt contains one or more
<typeelements . Each type has an "id" attribute. The
author of the design.xml file can use type's from the
library by referring to their id.

Depending on exact way the author may 'use' the types
from the library, this might look similar to the
following:

<xsl:template match="refer-to-lib-type">
<xsl:apply-templates
select="$lib/library/type[@id=current()/@id]"/>
</xsl:template>

I don't have templates that match the library (or the
types inside it), so
<xsl:apply-templates
select="$lib/library/type[@id=current()/@id]"/>
isn't going to match anything.

Create the templates to match the library elements, then.
It's good design anyway.

It's not that simple. There is no direct relation between the elements
in the library and the resulting SVG xml file.
The design xml file is leading. It only refers to the library for
looking up values from different types.

I think the solution from fildpauz fits my needs the
best:

<xsl:template match="root">
<xsl:apply-templates select="design"/>
<xsl:apply-templates select="documen t(library.xml)/"/>
</xsl:template>

You don't seem to understand how this solution would work.
As you yourself said, you don't have any templates that
would match the elements within your library, so
apply-templates select="documen t('library.xml' )" would
merely apply the default templates to this nodeset.

The only question that remains is this one:
"How can I perform xsl:apply-templates to the union of
the design and the library together?

You cannot achieve the results identical to using XInclude,
period. You may attempt to do something like

<xsl:variable
name="everythin g" select="/|document('foo' )"/>

I will try that, thanks.

but even if it works for you, I doubt it would really solve
your problems. You seem to be way over your head as it is,
and if you try juggling nodesets without accidentally
converting them to rtfs and ending you days in an asylum
due to the sheer frustration of it, you're bound to drown.

(see reaction below).

(There aren't any templates that directly match elements
in the library. There template that matches the design
element gets values from the library when it needs them
(using <xsl:variable name="..." select="...">)) . "

So? I believe I explained to you how to write XPath
expressions accessing other documents, it doesn't matter
whether you use them to apply templates, grab values or
populate variables. Either you want to do it the easy way
(in that case, deal with it--there's no easy way short of
XSLT2, and no, existing browsers do not support that) or
you don't really understand what's going on (and in that
case perhaps you should stop tinkering with real projects
before you break something, and start tinkering with toy
projects).

FYI, this is a real project and all I'm doing is making a small change
(I hope).
After all, the equivalent XInclude solution is really simple (but not
working in Firefox).
I just don't have the time to rebuild the complete XSLT file and also
it's already a pretty complex one. All I want to do is put the
<libraryeleme nt in another xml file. I understand your opinion: it's
bad/evil to hack this into the stylesheet, but in the real world there
are practical factors that I don't have control over.

Yes, I can start learning XSLT, XPath, XSchema, etc and rebuild the
whole thing, but that is going to take months and I just don't have
that time.

[p.lepin]

On Feb 22, 9:49 am, "Johan" <joh...@gmail.c omwrote:

On 21 feb, 15:28, p.le...@ctncorp .com wrote:

On Feb 21, 3:43 pm, "Johan" <joh...@gmail.c omwrote:

The only question that remains is this one:
"How can I perform xsl:apply-templates to the union
of the design and the library together?

You cannot achieve the results identical to using
XInclude, period. You may attempt to do something like

<xsl:variable
name="everythin g" select="/|document('foo' )"/>

I will try that, thanks.

You're not listening, are you? You *won't* get the results
identical to using XInclude without XSLT2 or EXSLT. (For
that matter, it's not as trivial as you seem to think it
should be with XSLT2 or EXSLT.) Modern browsers do not
support XSLT2 or EXSLT. If you use the union, you'll have
to check and probably rewrite all of your XPath expressions
referring to the children of library elements anyway.
There's no easy way. You'll have to do that. So don't turn
it into a maintenance nightmare for the guy who will have
to work with your code after you just for the sake of using
'union'. Do it the right way. Refer directly to the
external document.

(There aren't any templates that directly match
elements in the library. There template that matches
the design element gets values from the library when
it needs them (using <xsl:variable name="..."
select="...">)) .

So? I believe I explained to you how to write XPath
expressions accessing other documents, it doesn't
matter whether you use them to apply templates, grab
values or populate variables. Either you want to do it
the easy way (in that case, deal with it--there's no
easy way short of XSLT2, and no, existing browsers do
not support that) or you don't really understand what's
going on (and in that case perhaps you should stop
tinkering with real projects before you break
something, and start tinkering with toy projects).

FYI, this is a real project and all I'm doing is making a
small change (I hope).

You hope, indeed. I've been trying to tell you that it's
very unlikely you'll be doing a small change. Just because
your boss wants it tomorrow and you don't want to
disappoint him doesn't yet mean it's possible. Worse yet,
it might turn out to be possible, but the 'easy' solution
might introduce subtle bugs you'll spend the rest of your
life trying to weed out.

Worse yet, you might quit and *someone else* might have to
spend the rest of his bloody life trying to weed out the
subtle bugs you've introduced with this 'solution'.

After all, the equivalent XInclude solution is really
simple (but not working in Firefox).

Using fork(2) is really simple. Try implementing it in
bare-bones Lisp.

I just don't have the time to rebuild the complete XSLT
file and also it's already a pretty complex one.

Do you really believe wishful thinking is gonna solve your
problems? 'I don't have much time, I don't have the
expertise, but since I need it done yesterday, OF COURSE
there will be a simple solution.'

All I want to do is put the <libraryeleme nt in another
xml file. I understand your opinion: it's bad/evil to
hack this into the stylesheet,

No, you don't. It is bad/evil to hack this into the
stylesheet, but that's not the real problem. It's just that
this hack is very unlikely to work without other changes to
the stylesheet. So you'll hack this in, find out that
something doesn't work, or worse--that something *almost*
seems to work, and you'll try to fix this and that and the
other thing, and you'll end up going over all of your XPath
expressions anyway, and you'll get it working in the end,
the difference being that this idiotic hack will still be
in the code, while you could've done the same thing the
right way from the start.

I won't mention the fact that incremental problem-fixing is
likely to turn the code into the cockroach farm where
angels fear to tread.

but in the real world there are practical factors that I
don't have control over.

Invoking 'practical factors... don't have control...'
rarely solves problems.

--
Pavel Lepin

[Johan]

On 22 feb, 09:51, p.le...@ctncorp .com wrote:

On Feb 22, 9:49 am, "Johan" <joh...@gmail.c omwrote:

On 21 feb, 15:28, p.le...@ctncorp .com wrote:

On Feb 21, 3:43 pm, "Johan" <joh...@gmail.c omwrote:
The only question that remains is this one:
"How can I perform xsl:apply-templates to the union
of the design and the library together?

You cannot achieve the results identical to using
XInclude, period. You may attempt to do something like

<xsl:variable
name="everythin g" select="/|document('foo' )"/>

I will try that, thanks.

You're not listening, are you? You *won't* get the results
identical to using XInclude without XSLT2 or EXSLT. (For
that matter, it's not as trivial as you seem to think it
should be with XSLT2 or EXSLT.) Modern browsers do not
support XSLT2 or EXSLT. If you use the union, you'll have
to check and probably rewrite all of your XPath expressions
referring to the children of library elements anyway.

I'm I listening, but from a different point of view.
I'm going to use the union and if necessary I'm going to change the
"XPath expressions referring to the children of library elements".
Although I don't understand yet what exactly I will need to change.
The union (as far as I know it from school) doesn't change it inputs,
it only merges to sets.
If you are in a good mood you might want to give me some hints about
this :)

There's no easy way. You'll have to do that. So don't turn
it into a maintenance nightmare for the guy who will have
to work with your code after you just for the sake of using
'union'. Do it the right way. Refer directly to the
external document.

Sorry, but I don't understand what you are trying to say.
How can I refer directly to the external document (without creating
templates that match the library elements, I already explained that's
not what I want).

(There aren't any templates that directly match
elements in the library. There template that matches
the design element gets values from the library when
it needs them (using <xsl:variable name="..."
select="...">)) .

So? I believe I explained to you how to write XPath
expressions accessing other documents, it doesn't
matter whether you use them to apply templates, grab
values or populate variables.

I think you only explained "how to write XPath expressions accessing
other documents" for use with apply-templates.
How can I use it to grap/populate variables? Could you give an
example?

You hope, indeed. I've been trying to tell you that it's
very unlikely you'll be doing a small change. Just because
your boss wants it tomorrow and you don't want to
disappoint him doesn't yet mean it's possible. Worse yet,
it might turn out to be possible, but the 'easy' solution
might introduce subtle bugs you'll spend the rest of your
life trying to weed out.

Worse yet, you might quit and *someone else* might have to
spend the rest of his bloody life trying to weed out the
subtle bugs you've introduced with this 'solution'.

After all, the equivalent XInclude solution is really
simple (but not working in Firefox).

Using fork(2) is really simple. Try implementing it in
bare-bones Lisp.

I just don't have the time to rebuild the complete XSLT
file and also it's already a pretty complex one.

Do you really believe wishful thinking is gonna solve your
problems? 'I don't have much time, I don't have the
expertise, but since I need it done yesterday, OF COURSE
there will be a simple solution.'

All I want to do is put the <libraryeleme nt in another
xml file. I understand your opinion: it's bad/evil to
hack this into the stylesheet,

No, you don't. It is bad/evil to hack this into the
stylesheet, but that's not the real problem. It's just that
this hack is very unlikely to work without other changes to
the stylesheet. So you'll hack this in, find out that
something doesn't work, or worse--that something *almost*
seems to work, and you'll try to fix this and that and the
other thing, and you'll end up going over all of your XPath
expressions anyway, and you'll get it working in the end,
the difference being that this idiotic hack will still be
in the code, while you could've done the same thing the
right way from the start.

I don't mind changing all the XPath expressions that get values from
the <librarychild elements.
This is far more easy than changing the complete structure of the
stylesheet (eg. writing new templates that match the library
elements).

thanks for you help,
Johan.

[Johan]

On 22 feb, 09:51, p.le...@ctncorp .com wrote:

On Feb 22, 9:49 am, "Johan" <joh...@gmail.c omwrote:

On 21 feb, 15:28, p.le...@ctncorp .com wrote:

On Feb 21, 3:43 pm, "Johan" <joh...@gmail.c omwrote:

You're not listening, are you? You *won't* get the results
identical to using XInclude without XSLT2 or EXSLT. (For
that matter, it's not as trivial as you seem to think it
should be with XSLT2 or EXSLT.) Modern browsers do not
support XSLT2 or EXSLT. If you use the union, you'll have
to check and probably rewrite all of your XPath expressions
referring to the children of library elements anyway.
There's no easy way. You'll have to do that. So don't turn
it into a maintenance nightmare for the guy who will have
to work with your code after you just for the sake of using
'union'. Do it the right way. Refer directly to the
external document.

And what about the solution with external entities? See "C.27 How do
I include one XML file in another?" in the XML FAQ:
http://xml.silmaril.ie/authors/includes/

Can this be done with an XML schema in the same way?
That would be a really easy solution, right?

Johan.

[p.lepin]

On Feb 22, 12:34 pm, "Johan" <joh...@gmail.c omwrote:

On 22 feb, 09:51, p.le...@ctncorp .com wrote:

On Feb 22, 9:49 am, "Johan" <joh...@gmail.c omwrote:

On 21 feb, 15:28, p.le...@ctncorp .com wrote:
You cannot achieve the results identical to using
XInclude, period. You may attempt to do something
like

<xsl:variable
name="everythin g" select="/|document('foo' )"/>

I will try that, thanks.

You're not listening, are you? You *won't* get the
results identical to using XInclude without XSLT2 or
EXSLT. (For that matter, it's not as trivial as you
seem to think it should be with XSLT2 or EXSLT.) Modern
browsers do not support XSLT2 or EXSLT. If you use the
union, you'll have to check and probably rewrite all of
your XPath expressions referring to the children of
library elements anyway.

The union (as far as I know it from school) doesn't
change it inputs, it only merges to sets.

Precisely. That's the reason it won't emulate the XInclude
functionality.

If you are in a good mood

As a matter of fact, I'm not.

you might want to give me some hints about this :)

What's the point?

There's no easy way. You'll have to do that. So don't
turn it into a maintenance nightmare for the guy who
will have to work with your code after you just for the
sake of using 'union'. Do it the right way. Refer
directly to the external document.

Sorry, but I don't understand what you are trying to say.

Well, there's no royal path to geometry, as Euclid said to
Ptolemy. Perhaps you should start with the basics.

How can I refer directly to the external document
(without creating templates that match the library
elements, I already explained that's not what I want).

Read my previous posts in the thread.

I think you only explained "how to write XPath
expressions accessing other documents" for use with
apply-templates.

I explained how to write XPath expressions computing to
nodesets consisting of nodes in external documents. It
doesn't matter whether you use such expressions in select
attribute of apply-templates element, or value-of element,
or variable element. For that matter, I already explained
that in one of my previous posts, too.

How can I use it to grap/populate variables? Could you
give an example?

<xsl:variable name="$external-nodeset"
select=
"
document('exter nal.xml')//nodes[content='someth ing']
"/>

And what about the solution with external entities? See
"C.27 How do I include one XML file in another?" in the
XML FAQ:http://xml.silmaril.ie/authors/includes/

Google 'firefox external entity'. Summary: browsers don't
grok that. Browsers typically don't use validating parsers
and so couldn't care less for DTDs or schemata.

Can this be done with an XML schema in the same way?

No, and if it would've been possible, it wouldn't matter
anyway, because browsers typically don't use validating
parsers and therefore couldn't care less for DTDs or
schemata.

That would be a really easy solution, right?

Right. Only it doesn't work, as easy solutions tend to.

--
Pavel Lepin

[Arndt Jonasson]

On Feb 21, 10:45 am, "Johan" <joh...@gmail.c omwrote:

How can I include one XML file into another XML file (on the client
side, in Firefox)?

I think XInclude is just what I need, but Firefox doesn't support it:https://bugzilla.mozilla.org/show_bug.cgi?id=201754

It seems I also can use an "external entity reference", but that
depends on a DTD and I'm using XML Schema.

I don't think it depends on DTD's. Maybe this doesn't solve your
problem, but you can do:

$ cat foo.xml
<!DOCTYPE doc [
<!ENTITY part1 SYSTEM "foo1.xml"
]>

<doc>
<a>
hej
&part1;
</a>
</doc>
$ cat foo1.xml
<e>
hopp
</e>
$ xmllint --noent foo.xml
<?xml version="1.0"?>
<!DOCTYPE doc [
<!ENTITY part1 SYSTEM "foo1.xml">
]>
<doc>
<a>
hej
<e>
hopp
</e>

</a>
</doc>

[roy axenov]

On Feb 23, 7:52 pm, "Arndt Jonasson"
<arndt.jonas... @gmail.comwrote :

On Feb 21, 10:45 am, "Johan" <joh...@gmail.c omwrote:

How can I include one XML file into another XML file
(on the client side, in Firefox)?

I think XInclude is just what I need, but Firefox
doesn't support it:
https://bugzilla.mozilla.org/show_bug.cgi?id=201754

It seems I also can use an "external entity reference",
but that depends on a DTD and I'm using XML Schema.

I don't think it depends on DTD's. Maybe this doesn't
solve your problem, but you can do:

It certainly doesn't. Firefox does not parse external
entities.

$ cat foo.xml
<!DOCTYPE doc [
<!ENTITY part1 SYSTEM "foo1.xml"
]>

Hmmm... is that another case of google groups arbitrarily
discarding information it is considering discardable for
some mysterious reason of its own? I start thinking google
is past being just bad, it is now actively evil. Probably
has something to do with Parkinson's law.

--
roy axenov

[Arndt Jonasson]

On Feb 23, 8:30 pm, "roy axenov" <r_axe...@mail. ruwrote:

On Feb 23, 7:52 pm, "Arndt Jonasson"

$ cat foo.xml
<!DOCTYPE doc [
<!ENTITY part1 SYSTEM "foo1.xml"
]>

Hmmm... is that another case of google groups arbitrarily
discarding information it is considering discardable for
some mysterious reason of its own?

Are these four lines of mine the only ones you saw of foo.xml? When I
look at my own article, I see a lot more.

[roy axenov]

On Feb 26, 11:55 am, "Arndt Jonasson"
<arndt.jonas... @gmail.comwrote :

On Feb 23, 8:30 pm, "roy axenov" <r_axe...@mail. ru>
wrote:

On Feb 23, 7:52 pm, "Arndt Jonasson"

$ cat foo.xml
<!DOCTYPE doc [
<!ENTITY part1 SYSTEM "foo1.xml"
]>

Hmmm... is that another case of google groups
arbitrarily discarding information it is considering
discardable for some mysterious reason of its own?

Are these four lines of mine the only ones you saw of
foo.xml? When I look at my own article, I see a lot more.

Nope, I saw it all. I was talking about the fact that the
trailing angle bracket on the second line is missing. I've
noticed before that GG seems to have a strange dislike for
greater-than signs, but I'm not certain what was the
problem in this case.

--
roy axenov