«

On Feb 21, 3:43 pm, "Johan" <joh...@gmail.com> wrote:
> On 21 feb, 13:51, p.le...@ctncorp.com wrote:
> > On Feb 21, 2:14 pm, "Johan" <joh...@gmail.com> wrote:
> > > On 21 feb, 11:30, p.le...@ctncorp.com wrote:
> > > > <xsl:stylesheet version="1.0"
> > > > xmlnssl="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 <library> element contains one or more
> > > <type> elements. 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="document(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="document('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="everything" 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

On 21 feb, 15:28, p.le...@ctncorp.com wrote:
> On Feb 21, 3:43 pm, "Johan" <joh...@gmail.com> wrote:
> > On 21 feb, 13:51, p.le...@ctncorp.com wrote:
> > > On Feb 21, 2:14 pm, "Johan" <joh...@gmail.com> wrote:
> > > > On 21 feb, 11:30, p.le...@ctncorp.com wrote:
> > > > > <xsl:stylesheet version="1.0"
> > > > > xmlnssl="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 <library> element contains one or more
> > > > <type> elements. 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="document(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="document('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="everything" 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
<library> element 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.

On Feb 22, 9:49 am, "Johan" <joh...@gmail.com> wrote:
> On 21 feb, 15:28, p.le...@ctncorp.com wrote:
> > On Feb 21, 3:43 pm, "Johan" <joh...@gmail.com> wrote:
> > > 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="everything" 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 <library> element 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

On 22 feb, 09:51, p.le...@ctncorp.com wrote:
> On Feb 22, 9:49 am, "Johan" <joh...@gmail.com> wrote:
> > On 21 feb, 15:28, p.le...@ctncorp.com wrote:
> > > On Feb 21, 3:43 pm, "Johan" <joh...@gmail.com> wrote:
> > > > 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="everything" 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 <library> element 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 <library> child 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.

On 22 feb, 09:51, p.le...@ctncorp.com wrote:
> On Feb 22, 9:49 am, "Johan" <joh...@gmail.com> wrote:
>
> > On 21 feb, 15:28, p.le...@ctncorp.com wrote:
> > > On Feb 21, 3:43 pm, "Johan" <joh...@gmail.com> wrote:
> 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.

On Feb 22, 12:34 pm, "Johan" <joh...@gmail.com> wrote:
> On 22 feb, 09:51, p.le...@ctncorp.com wrote:
> > On Feb 22, 9:49 am, "Johan" <joh...@gmail.com> wrote:
> > > 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="everything" 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('external.xml')//nodes[content='something']
"/>

> 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

On Feb 21, 10:45 am, "Johan" <joh...@gmail.com> wrote:
> 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>

On Feb 23, 7:52 pm, "Arndt Jonasson"
<arndt.jonas...@gmail.com> wrote:
> On Feb 21, 10:45 am, "Johan" <joh...@gmail.com> wrote:
> > 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

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.

On Feb 26, 11:55 am, "Arndt Jonasson"
<arndt.jonas...@gmail.com> wrote:
> 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