www.digitalmars.com         C & C++   DMDScript  

D - Why create a DML? PI's are easier

reply Alex Vincent <jscript pacbell.net> writes:
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.
Jan 24 2002
parent reply "J. Daniel Smith" <j_daniel_smith deja.com> writes:
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.
Jan 24 2002
parent "J. Daniel Smith" <j_daniel_smith deja.com> writes:
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.
Jan 24 2002