concatenate several xml files into one big xml/html file?

[idiotprogrammer]

I have a rather basic question to ask. It reflects a lack of
understanding of how you solve problems with xml. But bear with me.

I'm a technical writer interested in producing good source code files.
The files will be created using an desktop xml editor, valid, etc. I
want to find a way to create a master document using relevant
portions of these multiple xml files which can then be converted into
a usable format.

The real situation I am dealing with.

I have recipes using this xml dtd
http://www.happy-monkey.net/recipebook/

However the xml dtd is not exactly what I need. For example, I want
to includes chapters with text and things unrelated to recipes. And
then I want other chapters which are only recipes. Then I want
chapters which contain recipes.

So I want to run an xslt scipt to run down the list of recipebook xml
files and make a long file which I can then embed it into a xml
dialect more suitable for publishing (such as docbook).

But what if I add another recipe? What if I add need to add another no-
recipe chapter.

The problem is: I have no idea how to get started. Is the solution
generally to create my own dtd/schema which a specialized tag for
importing data from other dtds.

I appreciate the concept of xml; but I've never understood how xml
solves these kinds of problems. Hopefully someone from this group can
offer a few hints (or at least URLs)

Robert Nagle
http://www.imaginaryplanet.net/weblogs/idiotprogrammer/
Houston, Texas

 

[idiotprogrammer]

Hello, does anyone want to give this question an old college try?

Maybe my question can be boiled down to this:

is it better to try to embed one flavor of xml within another? Or is
better to create a custom xml/schema that takes into account your
unique situation?


Thanks..

rj

 

[Joseph Kesselman]

is it better to try to embed one flavor of xml within another? Or is
better to create a custom xml/schema that takes into account your
unique situation?

It Depends.

If there's an XML-based and moderately-well-standardized language which
naturally describes what you want to describe, you probably don't want
to reinvent the wheel. One of the purposes of namespaces is specifically
to allow independently-developed grammars to be intermixed without the
risk of their trying to assign conflicting meanings to the same tokens.
(Note, however, that DTDs are inherently incompatable with namespaces;
if you want to do modern XML design you're sorta forced toward XML
Schemas... or toward one of their less-standard competetors)

On the other hand, if there isn't an existing language which is a good
fit, or if you don't trust the one you've found to be stable enough for
your needs, or if has features which would constitute a security risk in
your environment, you may want to reimplement and make that part of your
own custom grammar. As suggested above, the lack of namespace support in
DTDs makes collisions more common and is more likely to force
reimplementation as a result.

In other words, it's the same answer as with any other code reuse
question. Reuse can be a great productivity enhancer when the right
tools and libraries are available, or it can be a pain in the arse when
they aren't.

 

[idiotprogrammer]

So schemas allow you to incorporate different namespaces, but DTD's do
not. That is useful information.

I'll try it out.

rj

 

[Joseph Kesselman]

So schemas allow you to incorporate different namespaces, but DTD's do
not.

DTDs basically don't support namespaces at all. The best you can do with
a DTD is force specific prefix bindings and/or the default namespace.

I agree that schemas are harder to learn than DTDs. Unfortunately, I
really think DTDs are reaching the end of their useful lifespan.