I have been reading some threads on using D in combination with HTML and XML with great interest. Basically the ideas for XML were pretty basic, and Walter said that he did not know much about XML yet, but was interested. A lot of people said that XML, well, sucked, because it isn't easily human readable, but I would want these people and Walter to take a little while looking at some web sites about XML, and this website about programming:

http://mindprod.com/scid.html

Because if you combine XML with the ideas that Roedy Green talks about on
that page, you might change your mind about XML. The longer I have been
thinking about the XML threads I read, the more it seemed to me that saving
in any other format than XML made little sense!
Here's why:

Friends I have always write codeblocks like this:

void Func(int iCount) {
    for (int i=0; i<iCount; i++) {
        printf ("Hello world.\n");
    }
}

But I prefer:

void Func(int iCount)
{
    for (int i=0; i<iCount; i++)
    {
        printf ("Hello world.\n");
    }
}
or maybe:

void Func(int iCount)
{
    for (int i=0; i<iCount; i++)
        printf ("Hello world.\n");
}

All of these examples produce exactly the same program. They represent exactly the same data, they are only a different *view* on the data. Shouldn't changing the type of indentation for all source files you ever work with be as easy as changing one setting?

Source files for programming languages like Java, C/C++ or D are plain text
files, that contain both layout and data, something we learned from HTML
should be separated.
Now imagine that beneath the surface the IDE would save the code above in
XML like this:

<?xml version="1.0">
<Program>
    <Module name="main">
        <Function name="Func">
            <Return>void</Return>
            <Argument name="iCount">int</Argument>
            <CodeBlock>
                <For>
                    <ForInitializer>int i=0</ForInitializer>
                    <ForUpdater>i<iCount</ForUpdater>
                    <ForEvaluation>i<iCount</ForEvaluation>
                    <CodeBlock>
                        printf ("Hello world.\n");
                    </CodeBlock>
                </For>
            </CodeBlock>
        </Function>
    </Module>
</Program>

It looks very complex, but it contains the same information as the .d file. Now it would be a breeze to change all kinds of layout settings to create another .d file with exactly the same source code, but with a different view on that source code.

All you would need to do is make a XML specification for D code.
You probably could find some people here on the newsgroup to deal with
most of making such a specification, you would only have to make sure it
was language compliant. Then everyone could use that spec to implement
a tool to convert .d files to .xml files. And from .xml files you can go
back
to .html, .pdf, .doc or indeed other .d files without having to write *any*
software. You would only need to write an XSL
stylesheet that containes the rules of making the conversion. All the .xml
parsing and translation software can then be used.

If I sound strange, check out that website I was referring to, and read something about XML, I think it will get clear what I mean and you will become enthousiastic about the idea.

The XML code above was typed right into outlook from the top of
my head and probably will contain errors. Also it is probably not a
very good way to do this, but it illustrates the point.
I think a good language designer who knows a little about XML
could very easily make a smart and structured specification for saving
D source code as XML code. I however am merely a humble
programmer without a clue of the internals of compilers.  :)
Read that web page, it will change the way you look at source code!


--
Stijn
OddesE_XYZ@hotmail.com
http://www.OddesE.f2s.com
__________________________________________
Remove _XYZ from my address when replying by mail

This guy read my mind.  ;)

D certainly has an easier syntax for writing parsers for this kind of thing than C++ does.

Sean

"OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:a27qo9$11p3$1@digitaldaemon.com...
> I have been reading some threads on using D in combination with HTML and
XML
> with great interest. Basically the ideas for XML were pretty basic, and Walter said that he did not know much about XML yet, but was interested. A lot of people said that XML, well, sucked, because it isn't easily human readable, but I would want these people and Walter to take a little while looking at some web sites about XML, and this website about programming:
>
> http://mindprod.com/scid.html
>
> Because if you combine XML with the ideas that Roedy Green talks about on that page, you might change your mind about XML. The longer I have been thinking about the XML threads I read, the more it seemed to me that
saving
> in any other format than XML made little sense!
> Here's why:
>
> Friends I have always write codeblocks like this:
>
> void Func(int iCount) {
>     for (int i=0; i<iCount; i++) {
>         printf ("Hello world.\n");
>     }
> }
>
> But I prefer:
>
> void Func(int iCount)
> {
>     for (int i=0; i<iCount; i++)
>     {
>         printf ("Hello world.\n");
>     }
> }
> or maybe:
>
> void Func(int iCount)
> {
>     for (int i=0; i<iCount; i++)
>         printf ("Hello world.\n");
> }
>
> All of these examples produce exactly the same program. They represent exactly the same data, they are only a different *view* on the data. Shouldn't changing the type of indentation for all source files you ever work with be as easy as changing one setting?
>
> Source files for programming languages like Java, C/C++ or D are plain
text
> files, that contain both layout and data, something we learned from HTML
> should be separated.
> Now imagine that beneath the surface the IDE would save the code above in
> XML like this:
>
> <?xml version="1.0">
> <Program>
>     <Module name="main">
>         <Function name="Func">
>             <Return>void</Return>
>             <Argument name="iCount">int</Argument>
>             <CodeBlock>
>                 <For>
>                     <ForInitializer>int i=0</ForInitializer>
>                     <ForUpdater>i<iCount</ForUpdater>
>                     <ForEvaluation>i<iCount</ForEvaluation>
>                     <CodeBlock>
>                         printf ("Hello world.\n");
>                     </CodeBlock>
>                 </For>
>             </CodeBlock>
>         </Function>
>     </Module>
> </Program>
>
> It looks very complex, but it contains the same information as the .d
file.
> Now it would be a breeze to change all kinds of layout settings to create another .d file with exactly the same source code, but with a different view on that source code.
>
> All you would need to do is make a XML specification for D code.
> You probably could find some people here on the newsgroup to deal with
> most of making such a specification, you would only have to make sure it
> was language compliant. Then everyone could use that spec to implement
> a tool to convert .d files to .xml files. And from .xml files you can go
> back
> to .html, .pdf, .doc or indeed other .d files without having to write
*any*
> software. You would only need to write an XSL
> stylesheet that containes the rules of making the conversion. All the .xml
> parsing and translation software can then be used.
>
> If I sound strange, check out that website I was referring to, and read something about XML, I think it will get clear what I mean and you will become enthousiastic about the idea.
>
> The XML code above was typed right into outlook from the top of
> my head and probably will contain errors. Also it is probably not a
> very good way to do this, but it illustrates the point.
> I think a good language designer who knows a little about XML
> could very easily make a smart and structured specification for saving
> D source code as XML code. I however am merely a humble
> programmer without a clue of the internals of compilers.  :)
> Read that web page, it will change the way you look at source code!
>
>
> --
> Stijn
> OddesE_XYZ@hotmail.com
> http://www.OddesE.f2s.com
> __________________________________________
> Remove _XYZ from my address when replying by mail
>
>
>
>

This is all great, but I tell you one thing. I'm never going
to type in program in XML, and I don't want to use a converter
each time I'm going to compile it as well. Yes, IDEs, all is
great - but on *NIX many people still use vi to edit files and
command-line to compile them - and they won't be happy of any
additional step that is to be introduced. XML could be _one_
of possible input formats for D, but definitely not the primary.

Also, one idea about all this. What if D compiler supports some sort of "filters" - it feeds them the source code from the file and then compiles their output. This way, an XML filter could be easily written, as well as many others exotic formats; HTML could be done as a filter as well...

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a28v11$1pj1$1@digitaldaemon.com...
> This is all great, but I tell you one thing. I'm never going
> to type in program in XML, and I don't want to use a converter
> each time I'm going to compile it as well. Yes, IDEs, all is
> great - but on *NIX many people still use vi to edit files and
> command-line to compile them - and they won't be happy of any
> additional step that is to be introduced. XML could be _one_
> of possible input formats for D, but definitely not the primary.
>
> Also, one idea about all this. What if D compiler supports some sort of "filters" - it feeds them the source code from the file and then compiles their output. This way, an XML filter could be easily written, as well as many others exotic formats; HTML could be done as a filter as well...
>

Oh I definitely agree!
I didn't mean to say you should *write* the code in XML!  That would
be undoable!  :)
XML is not really meant to be read, let alone written, by humans.
It is a data representation format designed for computers.
This is what I imagine:

You type in your function in the editor, just like you would always do,
using
your own coding style, like this:

void Func(int iCount) {
    for (int i=0; i<iCount; i++) {
        printf ("Hello world.\n");
    }
}

To you there is absolutely *no* difference.
The editor stores the file in memory in normal .d format until it is saved,
at which time it saves it in .d or .xml format, whichever you prefer. Let's
assume for the moment you choose .xml, although there isn't a single reason
why saving in .d would be impossible or even difficult.
When you run your program, the IDE sends plain .d code (no XML) to the
compiler, which compiles it, after which it can be linked and run. No
changes there either, the compiler stays exactly the same, no need for any
special filters or anything.
After you finish your work and close the IDE, the files are saved on your
harddisk in .xml format. The next day you open the .xml files again and see
your function like this:

void Func(int iCount) {
    for (int i=0; i<iCount; i++) {
        printf ("Hello world.\n");
    }
}

exactly the same!
But now I come in. You decide you need another programmer for, say,
maintenance coding, and you hire me for the job. I however, have my own
coding style, and set my IDE to different settings, so when I load your .xml
file containing the Func function, I see this:

void Func (int iCount)
{
    for (int i=0; i<iCount; i++)
    {
        printf ("Hello world.\n");
    }
}

And, when it comes to the official documentation, written in say HTML, you would only need one .XSL stylesheet that defines the conversion, to produce .html files that all use exactly the same coding style and syntax coloring options. Better still, because the .xml files contain no information about style, just the pure code, changing the company style for all thousand programmers would be as easy as changing one XSL stylesheet and recreating the documentation files from the original .xml source code files. Every programmer in the organisation could use his own personal style, without having to compromise to the style of any other programmer, and the .xml files wouldn't change one bit!

If you now think to yourself, this is too good to be true, and you have all kinds of objections for why this can't be possible or would be very impractical, let me try to address some of the first ones that came into my mind:

- XML files are unreadble for humans:

As described above, this should not be a problem, you should never have to read or write a single letter of XML. You code in D, like you always did.

- XML files are too complex:

Although .xml files indeed do look very complex to humans, to computers they are actually very easily parsable, they were intentionally designed that way.

- I would have to choose between .xml and .d file formats:

XML was designed with format conversions in mind. The conversion from .d to XML is specific to the D language, so you would need a tool, filter, plugin, component or whatever to do that, but conversion from XML to any other format, including HTML, PDF, DOC or just back to D again would only require writing a XSL stylesheet. There are standard XML parsers and conversion tools that can then do the conversion job. This means you could use saving as .d for years, then one day convert all these .d files to .xml in one large swoop and immediately gain all the benefits of .xml. It also works the other way around. You could save as .xml for years and then one day convert them all back to .d again. At no point in time would you ever be forced to choose between saving as .d or as .xml without a very simple way to reverse that choice.

- I would need to write complex stylesheets:

Most probably not. You *could* write your own stylesheet, but you probably would leave such  tasks to the IDE or 3rd-party specialised tools.

- To include the option of saving as XML would require an enormeous amount of work, special compilers and IDE's, and would overall be a threat to using D on different platforms:

Definitely not.
To include the option to save as .xml you would need:
1) A solid XML specification for translating D code to XML.
2) A tool to convert D code to XML according to that specification.
3) A tool to create custom stylesheets based on settings such as indentation
type,
tabs/versus spaces etc.

1) and 2) are vital, but the stylesheets could be written by hand in the
beginning, and a few common ones with standard code style features could be
placed on a website.
Also, only the XML specification is time critical, because you could use D
without XML just fine for as long as it would take for the D to XML
conversion tools to be designed. Ofcourse the XML specification needs to be
well defined before you can start building the conversion tool(s).
Designing a solid XML specification for translating D code to XML wouldn't
be easy, but it would be peanuts compared to designing a whole language and
largely follows from the syntax and structure rules for D. It does need to
be an 'official' specification, because if there would be many (slightly)
different versions you would soon lose a lot of the big benefits of .xml. In
that respect it is like a programming language, if everyone uses slightly
different versions of a language, maintaining and porting code becomes
difficult.

And that's it. IDE's would only need one option more, Save As XML, which
would send the .d code to the conversion tool which would then save it to
disk as .xml. On loading a .xml file, they would send it to a standard XML
transformation tool with the stylesheet the user wants and then the file
would be loaded into memory in D format as always. Optionally the IDE would
allow for code style settings to be saved to a stylesheet using the
stylesheet creation tool.
The compiler would not change at all.

Because you are never forced to use .xml files and because a standard .d to .xml tool would be relatively easy to design for all platforms, and because .xml to .d conversions can be done with just a stylesheet and standard tools that already exist for all platforms, XML wouldn't be a threat to using D on multiple platforms at all. In the contrary!

Sorry for the very long story, but I just *love* the idea!


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
__________________________________________
Remove _XYZ from my address when replying by mail

The only thing about this that I'd tweak is setting up the compiler to accept the XML file directly.

1.  the D compiler already has support for "D in HTML", since it already
deals with a .htm file, it can deal with a .xml file too
2.  Given that the compiler already has a mechanism for converting .htm file
to D, adding support for a .xml file using a built-in XSLT stylesheet is
straightfoward.
3.  Most importantly, by the compiler supporting a particular "D in XML"
dialect, we avoid a bunch of different and incompatiable styles of XML.  (Of
course, with another XSLT tranform you can convert from one "D in XML"
dialect to another).

   Dan

"OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:a29u9b$2ola$1@digitaldaemon.com...
> "Pavel Minayev" <evilone@omen.ru> wrote in message news:a28v11$1pj1$1@digitaldaemon.com...
> > This is all great, but I tell you one thing. I'm never going
> > to type in program in XML, and I don't want to use a converter
> > each time I'm going to compile it as well. Yes, IDEs, all is
> > great - but on *NIX many people still use vi to edit files and
> > command-line to compile them - and they won't be happy of any
> > additional step that is to be introduced. XML could be _one_
> > of possible input formats for D, but definitely not the primary.
> >
> > Also, one idea about all this. What if D compiler supports some sort of "filters" - it feeds them the source code from the file and then compiles their output. This way, an XML filter could be easily written, as well as many others exotic formats; HTML could be done as a filter as well...
> >
>
> Oh I definitely agree!
> I didn't mean to say you should *write* the code in XML!  That would
> be undoable!  :)
> XML is not really meant to be read, let alone written, by humans.
> It is a data representation format designed for computers.
> This is what I imagine:
>
> You type in your function in the editor, just like you would always do,
> using
> your own coding style, like this:
>
> void Func(int iCount) {
>     for (int i=0; i<iCount; i++) {
>         printf ("Hello world.\n");
>     }
> }
>
> To you there is absolutely *no* difference.
> The editor stores the file in memory in normal .d format until it is
saved,
> at which time it saves it in .d or .xml format, whichever you prefer.
Let's
> assume for the moment you choose .xml, although there isn't a single
reason
> why saving in .d would be impossible or even difficult.
> When you run your program, the IDE sends plain .d code (no XML) to the
> compiler, which compiles it, after which it can be linked and run. No
> changes there either, the compiler stays exactly the same, no need for any
> special filters or anything.
> After you finish your work and close the IDE, the files are saved on your
> harddisk in .xml format. The next day you open the .xml files again and
see
> your function like this:
>
> void Func(int iCount) {
>     for (int i=0; i<iCount; i++) {
>         printf ("Hello world.\n");
>     }
> }
>
> exactly the same!
> But now I come in. You decide you need another programmer for, say,
> maintenance coding, and you hire me for the job. I however, have my own
> coding style, and set my IDE to different settings, so when I load your
.xml
> file containing the Func function, I see this:
>
> void Func (int iCount)
> {
>     for (int i=0; i<iCount; i++)
>     {
>         printf ("Hello world.\n");
>     }
> }
>
> And, when it comes to the official documentation, written in say HTML, you would only need one .XSL stylesheet that defines the conversion, to
produce
> .html files that all use exactly the same coding style and syntax coloring options. Better still, because the .xml files contain no information about style, just the pure code, changing the company style for all thousand programmers would be as easy as changing one XSL stylesheet and recreating the documentation files from the original .xml source code files. Every programmer in the organisation could use his own personal style, without having to compromise to the style of any other programmer, and the .xml files wouldn't change one bit!
>
> If you now think to yourself, this is too good to be true, and you have
all
> kinds of objections for why this can't be possible or would be very impractical, let me try to address some of the first ones that came into
my
> mind:
>
> - XML files are unreadble for humans:
>
> As described above, this should not be a problem, you should never have to read or write a single letter of XML. You code in D, like you always did.
>
> - XML files are too complex:
>
> Although .xml files indeed do look very complex to humans, to computers
they
> are actually very easily parsable, they were intentionally designed that way.
>
> - I would have to choose between .xml and .d file formats:
>
> XML was designed with format conversions in mind. The conversion from .d
to
> XML is specific to the D language, so you would need a tool, filter,
plugin,
> component or whatever to do that, but conversion from XML to any other format, including HTML, PDF, DOC or just back to D again would only
require
> writing a XSL stylesheet. There are standard XML parsers and conversion tools that can then do the conversion job. This means you could use saving as .d for years, then one day convert all these .d files to .xml in one large swoop and immediately gain all the benefits of .xml. It also works
the
> other way around. You could save as .xml for years and then one day
convert
> them all back to .d again. At no point in time would you ever be forced to choose between saving as .d or as .xml without a very simple way to
reverse
> that choice.
>
> - I would need to write complex stylesheets:
>
> Most probably not. You *could* write your own stylesheet, but you probably would leave such  tasks to the IDE or 3rd-party specialised tools.
>
> - To include the option of saving as XML would require an enormeous amount of work, special compilers and IDE's, and would overall be a threat to
using
> D on different platforms:
>
> Definitely not.
> To include the option to save as .xml you would need:
> 1) A solid XML specification for translating D code to XML.
> 2) A tool to convert D code to XML according to that specification.
> 3) A tool to create custom stylesheets based on settings such as
indentation
> type,
> tabs/versus spaces etc.
>
> 1) and 2) are vital, but the stylesheets could be written by hand in the beginning, and a few common ones with standard code style features could
be
> placed on a website.
> Also, only the XML specification is time critical, because you could use D
> without XML just fine for as long as it would take for the D to XML
> conversion tools to be designed. Ofcourse the XML specification needs to
be
> well defined before you can start building the conversion tool(s). Designing a solid XML specification for translating D code to XML wouldn't be easy, but it would be peanuts compared to designing a whole language
and
> largely follows from the syntax and structure rules for D. It does need to be an 'official' specification, because if there would be many (slightly) different versions you would soon lose a lot of the big benefits of .xml.
In
> that respect it is like a programming language, if everyone uses slightly different versions of a language, maintaining and porting code becomes difficult.
>
> And that's it. IDE's would only need one option more, Save As XML, which would send the .d code to the conversion tool which would then save it to disk as .xml. On loading a .xml file, they would send it to a standard XML transformation tool with the stylesheet the user wants and then the file would be loaded into memory in D format as always. Optionally the IDE
would
> allow for code style settings to be saved to a stylesheet using the
> stylesheet creation tool.
> The compiler would not change at all.
>
> Because you are never forced to use .xml files and because a standard .d
to
> .xml tool would be relatively easy to design for all platforms, and
because
> .xml to .d conversions can be done with just a stylesheet and standard
tools
> that already exist for all platforms, XML wouldn't be a threat to using D
on
> multiple platforms at all. In the contrary!
>
> Sorry for the very long story, but I just *love* the idea!
>
>
> --
> Stijn
> OddesE_XYZ@hotmail.com
> http://OddesE.cjb.net
> __________________________________________
> Remove _XYZ from my address when replying by mail
>
>
>

"J. Daniel Smith" <j_daniel_smith@deja.com> wrote in message news:a2a3i3$2s14$1@digitaldaemon.com...

> 1.  the D compiler already has support for "D in HTML", since it already deals with a .htm file, it can deal with a .xml file too

There is one major difference here. The way D handles HTML is pretty straightforward - it just throws away most tags, and only handles <code> specially. For XML, as you propose it, keywords are tags as well - so you got to have an XML parser embedded into the compiler. Why not make it an external, "filter" program?

> 2.  Given that the compiler already has a mechanism for converting .htm
file
> to D, adding support for a .xml file using a built-in XSLT stylesheet is straightfoward.

Again it has to understand XSLT...

> 3.  Most importantly, by the compiler supporting a particular "D in XML" dialect, we avoid a bunch of different and incompatiable styles of XML.
(Of
> course, with another XSLT tranform you can convert from one "D in XML" dialect to another).

Walter could just define one standard to be "official", without implementing it in the compiler. The language is in early stage of development, and if you write a clean syntax proposal AND an XML2D parser/translator for it, why not "apply" it?

"J. Daniel Smith" <j_daniel_smith@deja.com> wrote in message news:a2a3i3$2s14$1@digitaldaemon.com...
> The only thing about this that I'd tweak is setting up the compiler to accept the XML file directly.
>
> 1.  the D compiler already has support for "D in HTML", since it already deals with a .htm file, it can deal with a .xml file too

Correct, but it just takes the code between <CODE> and </CODE> tags
and strips all other HTML tags in between...I would like to see a format
that
captures the structure of the code, not just adds some fancy formatting
options to the plain text code.


> 2.  Given that the compiler already has a mechanism for converting .htm
file
> to D, adding support for a .xml file using a built-in XSLT stylesheet is straightfoward.

Agreed.  I hadn't thought of that. Just using a built-in XSLT stylesheet and
the
already existing standard conversion tools would be relatively easy.


> 3.  Most importantly, by the compiler supporting a particular "D in XML" dialect, we avoid a bunch of different and incompatiable styles of XML.
(Of
> course, with another XSLT tranform you can convert from one "D in XML" dialect to another).
>
>    Dan


Definitely this would be the ideal situation, but it requires extra work on
the writer
of the compiler. I think the most important thing is that a good, solid XML
specification for converting D code to XML is made. I bet there are people
on this newsgroup capable of doing that. DigitalMars would act like a
standards
committee, approving and embracing specification drafts, and then finally
'releasing' the final specification by publishing it on their Website. Any
compiler
would then be able to implement the specification if, when and how they see
fit.


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
__________________________________________
Remove _XYZ from my address when replying by mail

"OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:a2a572$2t70$1@digitaldaemon.com...

> specification for converting D code to XML is made. I bet there are people
> on this newsgroup capable of doing that. DigitalMars would act like a
> standards
> committee, approving and embracing specification drafts, and then finally
> 'releasing' the final specification by publishing it on their Website. Any
> compiler
> would then be able to implement the specification if, when and how they
see
> fit.

IMHO the best way to do that is to write an external filter in platform- independent D. Then, any implementation of D compiler, ported to any platform, can recompile that filter there, and author may rely on it later _without writing a piece of his own code to do that_. On other hand, if he wants, he can incorporate XML support into the compiler itself. Either way, since it costs him nothing to add this support, thus encouraging people to do so.

> IMHO the best way to do that is to write an external filter in platform- independent D.


Not persé. You see, you have to differentiate thinking about
the conversion from D to XML, which is difficult because a
tailor-made tool is needed, and the conversion from XML to
D, which is relatively easy, because you only need a
stylesheet (which is platform independent and only needs to
be written once) and the standard conversion tools already
available for almost every platform. Most of these conversion
tools are available as API calls so the compiler could just load
the stylesheet and make the necessary API calls.


"Pavel Minayev" <evilone@omen.ru> wrote in message news:a2a5j8$2thb$1@digitaldaemon.com...
> "OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:a2a572$2t70$1@digitaldaemon.com...
>
> > specification for converting D code to XML is made. I bet there are
people
> > on this newsgroup capable of doing that. DigitalMars would act like a
> > standards
> > committee, approving and embracing specification drafts, and then
finally
> > 'releasing' the final specification by publishing it on their Website.
Any
> > compiler
> > would then be able to implement the specification if, when and how they
> see
> > fit.
>
> IMHO the best way to do that is to write an external filter in platform- independent D. Then, any implementation of D compiler, ported to any platform, can recompile that filter there, and author may rely on it later _without writing a piece of his own code to do that_. On other hand, if he wants, he can incorporate XML support into the compiler itself. Either way, since it costs him nothing to add this support, thus encouraging people to do so.
>

"OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:a2a7na$2ulr$1@digitaldaemon.com...

> tailor-made tool is needed, and the conversion from XML to
> D, which is relatively easy, because you only need a
> stylesheet (which is platform independent and only needs to
> be written once) and the standard conversion tools already
> available for almost every platform. Most of these conversion
> tools are available as API calls so the compiler could just load
> the stylesheet and make the necessary API calls.

APIs are usually not so easy as they tend to be.
I wonder if there is a multi-platform console-mode XSLT converter
(for any platform D could be ported to), though... it could
be used for that purpose.