WikiPage Modularizing modified by OmniMark Code

OmniMark Code — Mon, 14 May 2012 15:37:07 -0000

--- v1 
+++ v2 
@@ -5,46 +5,49 @@
 
 If you want to keep your OmniMark scripts robust, the only way to scrap your boilerplate it to modularize it  away. Beginning with OmniMark 9.1, all the code we have seen so far has been packaged in two reusable library  modules shipped with OmniMark: `omxmlwrite.xmd` and `beta/omsgmlwrite.xmd`. The interface for the former library  is described in the [OmniMark  documentation](http://developers.omnimark.com/login/docs/html/library/129.htm). A typical  use would look somewhat like this:  
 
-    import "omxmlwrite.xmd" prefixed by xml.
-    
-    process
-       do xml-parse scan #main-input
-          output xml.written from "%c"
-       done
-      
-
-
++import "omxmlwrite.xmd" prefixed by xml.
+ 
+process
+   do xml-parse scan #main-input
+      output xml.written from "%c"
+   done
+  
+
+
 There is a catch, however: your rules that used to output XML markup now need to emit markup events instead. So  rather than something like this:  
 
-    element #implied
-       output "<%q"
-       repeat over specified attributes as a
-          output " " || key of attribute a || "=%"" || attribute a || "%""
-       again
-       output ">%c"
-    
-    element "graphical-object"
-       output "%c"
-
++element #implied
+   output "<%q"
+   repeat over specified attributes as a
+      output " " || key of attribute a || "=%"" || attribute a || "%""
+   again
+   output ">%c</%q>"
+ 
+element "graphical-object"
+   output "<figure><image href=%"%v(object-location)%"/>%c</figure>"
+
 
 your rules should look like this:   
 
-    element #implied
-       signal throw #markup-start #current-markup-event
-       output "%c"
-       signal throw #markup-end #current-markup-event
-    
-    element "graphical-object"
-       local markup-element-event figure initial { create-element-event (declared-elements of target-dtd){"figure"} }
-       local markup-element-event image  initial { create-element-event (declared-elements of target-dtd){"image"}
-                                                             attributes { attribute "object-location" with key "href" } }
-    
-       signal throw #markup-start figure
-       signal throw #markup-start image
-       signal throw #markup-end image
-       output "%c"
-       signal throw #markup-end figure
-
++element #implied
+   signal throw #markup-start #current-markup-event
+   output "%c"
+   signal throw #markup-end #current-markup-event
+ 
+element "graphical-object"
+   local markup-element-event figure initial { create-element-event (declared-elements of target-dtd){"figure"} }
+   local markup-element-event image  initial { create-element-event (declared-elements of target-dtd){"image"}
+                                                         attributes { attribute "object-location" with key "href" } }
+ 
+   signal throw #markup-start figure
+   signal throw #markup-start image
+   signal throw #markup-end image
+   output "%c"
+   signal throw #markup-end figure
+
 
 Besides the ability to use the `omxmlwrite` library and get rid of the boilerplate, this style of coding has the  benefit of easy pipeline construction, but you can find more on that topic  [elsewhere](http://developers.omnimark.com/markup-pipelines.html).

WikiPage Modularizing modified by OmniMark Code

OmniMark Code — Fri, 11 May 2012 18:43:12 -0000

Modularizing ============= You may be wondering at this point if every OmniMark program that outputs SGML or XML markup really has to contain over fifty lines of boilerplate code. Of course it doesn't. You may not want the processing instructions and comments from the input reproduced in the output. And perhaps your input markup never contains any escaped newline characters in attribute values. On the other hand, maybe you just haven't encountered them yet. If you want to keep your OmniMark scripts robust, the only way to scrap your boilerplate it to modularize it away. Beginning with OmniMark 9.1, all the code we have seen so far has been packaged in two reusable library modules shipped with OmniMark: `omxmlwrite.xmd` and `beta/omsgmlwrite.xmd`. The interface for the former library is described in the [OmniMark documentation](http://developers.omnimark.com/login/docs/html/library/129.htm). A typical use would look somewhat like this: import "omxmlwrite.xmd" prefixed by xml. process do xml-parse scan #main-input output xml.written from "%c" done There is a catch, however: your rules that used to output XML markup now need to emit markup events instead. So rather than something like this: element #implied output "<%q" repeat over specified attributes as a output " " || key of attribute a || "=%"" || attribute a || "%"" again output ">%c" element "graphical-object" output "

%c" your rules should look like this: element #implied signal throw #markup-start #current-markup-event output "%c" signal throw #markup-end #current-markup-event element "graphical-object" local markup-element-event figure initial { create-element-event (declared-elements of target-dtd){"figure"} } local markup-element-event image initial { create-element-event (declared-elements of target-dtd){"image"} attributes { attribute "object-location" with key "href" } } signal throw #markup-start figure signal throw #markup-start image signal throw #markup-end image output "%c" signal throw #markup-end figure Besides the ability to use the `omxmlwrite` library and get rid of the boilerplate, this style of coding has the benefit of easy pipeline construction, but you can find more on that topic [elsewhere](http://developers.omnimark.com/markup-pipelines.html).

Recent changes to Modularizing

WikiPage Modularizing modified by OmniMark Code

WikiPage Modularizing modified by OmniMark Code