Ladies and gentlemen, I honestly find myself wondering why we would go to the trouble of creating a new XML language specifically for D.

I would submit that it would be far easier to specify XML processing instructions for the D programming language than to create a D Markup Language.

Processing instructions come in the format <?target data data data ... more data ... ?>.  The target specifies where the processing instruction takes place.

Suppose we had two new targets which we reserved for the D programming language.

<?d-server ?> would be a processing instruction for D to run on a server (as an Apache module, for instance).  <?d-client ?> would be a processing instruction for D to run on a client browser (such as Mozilla).

You could embed the D language as the data section of the processing instruction without needing to create a new language.  Then, with the right browser support (which you'll need anyway), you can run the D language natively or use an XSLT stylesheet to transform the language appropriately.

Yes, you can retrieve the D language directly from the processing instruction using XSLT.

The idea of DML is a generalization of "Embedding D in HTML" as outlined at http://www.digitalmars.com/d/html.html.

Currently, the D compiler has special code to strip all of the HTML tags from <code> blocks in a .htm file.  Now, let's assume that our .htm file is XML-compliant, that is it's an XHTML document.  The special code in the compiler can now be replaced by a more general XSLT transform using a XHTMLtoD.xsl stylesheet.  This doesn't change the current behavior of the compiler one bit - it merely alters how it goes about processing a .htm file.

Now, if you do a "view source" on the above webpage, you'll see that the
<code> block contains:
    import Object;<br>
    import stdio;<br>
    <br>
    int <font size=+1><b>main</b></font>()<br>
    {<br>
     &nbsp;<font color=red>printf</font>(<u>&quot;hello
world\n&quot;</u>);<br>
     &nbsp;return 0;<br>
    }
this is both data (the D source code) and display (the HTML elements) mixed
together.  If we use .htm files as our "copy of record" when doing D
development, then I'm always going to see the printf() above in red because
of the <font color=red> tag.  What if I'd rather see function names
italicized instead?  There's no easy way to change '<font
color=red>printf</font>' to '<i>printf</i>' because I know nothing about the
purpose of the '<font color=red>' tag.

Thus, DML is the idea of encoding the D source code as XML data; among many
other things, this makes it trivial to format HTML (really XHTML) suited to
particular tastes.  The above code snipet might then look something like
   <d:import name="Object" />
   <d:import name="stdio" />
   <d_op:function name="main" return="int">
      <d_op:call name="printf">
         <d_op:arg type="string">hello world\n</d:op:arg>
      </d_op:call>
      <d:return value="0" />
   </d_op:function>
To get HTML, a DMLtoXHTML.xsl stylesheet would tranform the DML into the
original HTML.  The compiler would just use a different XSLT transfor
DMLtoD.xsl to generate plain D source code.

   Dan

"Alex Vincent" <jscript@pacbell.net> wrote in message news:3C5041A6.90005@pacbell.net...
> Ladies and gentlemen, I honestly find myself wondering why we would go to the trouble of creating a new XML language specifically for D.
>
> I would submit that it would be far easier to specify XML processing instructions for the D programming language than to create a D Markup Language.
>
> Processing instructions come in the format <?target data data data ... more data ... ?>.  The target specifies where the processing instruction takes place.
>
> Suppose we had two new targets which we reserved for the D programming language.
>
> <?d-server ?> would be a processing instruction for D to run on a server
> (as an Apache module, for instance).  <?d-client ?> would be a
> processing instruction for D to run on a client browser (such as Mozilla).
>
> You could embed the D language as the data section of the processing instruction without needing to create a new language.  Then, with the right browser support (which you'll need anyway), you can run the D language natively or use an XSLT stylesheet to transform the language appropriately.
>
> Yes, you can retrieve the D language directly from the processing instruction using XSLT.
>

I've posted this message to http://jdanielsmith.org/DML and added sample files to illustrate what can be done with XML and XSLT.

   Dan


"J. Daniel Smith" <j_daniel_smith@deja.com> wrote in message news:a2psa7$38$1@digitaldaemon.com...
> The idea of DML is a generalization of "Embedding D in HTML" as outlined
at
> http://www.digitalmars.com/d/html.html.
>
> Currently, the D compiler has special code to strip all of the HTML tags from <code> blocks in a .htm file.  Now, let's assume that our .htm file
is
> XML-compliant, that is it's an XHTML document.  The special code in the compiler can now be replaced by a more general XSLT transform using a XHTMLtoD.xsl stylesheet.  This doesn't change the current behavior of the compiler one bit - it merely alters how it goes about processing a .htm file.
>
> Now, if you do a "view source" on the above webpage, you'll see that the
> <code> block contains:
>     import Object;<br>
>     import stdio;<br>
>     <br>
>     int <font size=+1><b>main</b></font>()<br>
>     {<br>
>      &nbsp;<font color=red>printf</font>(<u>&quot;hello
> world\n&quot;</u>);<br>
>      &nbsp;return 0;<br>
>     }
> this is both data (the D source code) and display (the HTML elements)
mixed
> together.  If we use .htm files as our "copy of record" when doing D development, then I'm always going to see the printf() above in red
because
> of the <font color=red> tag.  What if I'd rather see function names italicized instead?  There's no easy way to change '<font color=red>printf</font>' to '<i>printf</i>' because I know nothing about
the
> purpose of the '<font color=red>' tag.
>
> Thus, DML is the idea of encoding the D source code as XML data; among
many
> other things, this makes it trivial to format HTML (really XHTML) suited
to
> particular tastes.  The above code snipet might then look something like
>    <d:import name="Object" />
>    <d:import name="stdio" />
>    <d_op:function name="main" return="int">
>       <d_op:call name="printf">
>          <d_op:arg type="string">hello world\n</d:op:arg>
>       </d_op:call>
>       <d:return value="0" />
>    </d_op:function>
> To get HTML, a DMLtoXHTML.xsl stylesheet would tranform the DML into the
> original HTML.  The compiler would just use a different XSLT transfor
> DMLtoD.xsl to generate plain D source code.
>
>    Dan
>
> "Alex Vincent" <jscript@pacbell.net> wrote in message news:3C5041A6.90005@pacbell.net...
> > Ladies and gentlemen, I honestly find myself wondering why we would go to the trouble of creating a new XML language specifically for D.
> >
> > I would submit that it would be far easier to specify XML processing instructions for the D programming language than to create a D Markup Language.
> >
> > Processing instructions come in the format <?target data data data ... more data ... ?>.  The target specifies where the processing instruction takes place.
> >
> > Suppose we had two new targets which we reserved for the D programming language.
> >
> > <?d-server ?> would be a processing instruction for D to run on a server (as an Apache module, for instance).  <?d-client ?> would be a processing instruction for D to run on a client browser (such as
Mozilla).
> >
> > You could embed the D language as the data section of the processing instruction without needing to create a new language.  Then, with the right browser support (which you'll need anyway), you can run the D language natively or use an XSLT stylesheet to transform the language appropriately.
> >
> > Yes, you can retrieve the D language directly from the processing instruction using XSLT.
> >
>
>