I agree that this sounds like an interesting project, but also that you'd
be well-advised to get into XSLT and see what it does (and doesn't do).
XSLT is designed explicitly to support XML-to-XML transformations. Although
it is *not* specified as a "general-purpose" transformation utility, it is
pretty powerful, and since it's a standard supporting a commodity market in
tools, it's hard to compete with (this is undoubtedly why you see such a
scarcity of other tools like this out there). Also, in the next version,
it'll be even more powerful.
One interesting angle of your approach here is that you are interested in
transformations based on a mapping of the *model* (the DTD) -- whereas XSLT
does not refer to a DTD, only to the XML document itself (viewed as a
tree). In the real world, we do use DTDs, and a writer of an XSLT transform
will often work with a DTD to see what to expect. But this is done by hand,
whereas you're suggesting that it could be automated.
I also agree with Simon that you may find it difficult to build a very good
heuristic to determine how a mapping should happen. But you could certainly
provide an interface allowing a human being to help.
If I were thinking of building this, I would consider doing it on top of
XSLT. That is, the tool would create an XSLT stylesheet, which could then
be used with any number of conformant processors (of which there are many).
If it were considered as a "shell" or environment for XSLT, it might also
be nice to add in a feature to work around one of XSLT's particular
weaknesses, namely that it cannot preserve entity references, but resolves
them all. (Not that this can't be done easily enough by other means.)
Simon also mentions Omnimark, which is very cool but which I think is just
as hard to learn as XSLT.
At 09:41 AM 12/20/00 -0500, Simon St. Laurent wrote:
>At 01:58 AM 12/20/00 -0600, John Reinke wrote:
> >I'm still new to some XML concepts, so I'd like to run this idea past those
> >on the list to make sure it makes as much sense as I think it does.
> >I'm about to begin a major project to create an experimental converter of
> >XML files from one DTD to another DTD. Basically, if one person has XML
> >files that follow one DTD, but they need to convert the files to follow
> >someone else's DTD, this converter would try to "guess" the translation for
> >each element in the first DTD to the second by looking at both DTDs and an
> >XML file representing either or both DTDs.
> >1) I know that this won't be a simple task, but does my description make
>Yes, though I think you'll find it a difficult task to make 'guesses' based
>on DTDs alone. You might want to develop some kind of interface which
>makes it easy for humans to assist in that guessing, and then remember the
> >2) There appear to be many converters already in exsistence, many of which
> >are commercially available, which convert practially anything _to_ XML or
> >_from_ XML, but I've not seen anything to convert between XML formats. In
> >most cases, I understand that someone creates a separate program to convert
> >only between two specific formats. Has anyone seen something already in
> >exsistence which is similar to what I'm proposing?
>A lot of people are pushing XSLT as the Swiss Army Knife of XML-to-XML
>conversion. It works well for some tasks, but not as well for others. I'd
>love to see an alternative with a gentler learning curve, certainly!
>(Omnimark is another frequently mentioned tool for XML transformations
>which might be worth a look.)
Wendell Piez mailto:[log in to unmask]
Mulberry Technologies, Inc. http://www.mulberrytech.com
17 West Jefferson Street Direct Phone: 301/315-9635
Suite 207 Phone: 301/315-9631
Rockville, MD 20850 Fax: 301/315-8285
Mulberry Technologies: A Consultancy Specializing in SGML and XML