Macro Syntax
Macro Syntax
By Chuck Shotton, cshotton@biap.com
Chuck Shotton's spec for the <macrosyntax> tag.
See Page Rendering Proposed Standard for background.
This is just a first cut at the
syntax. I don't presume to have gotten it right in this iteration, but I think it is the meat of what we discussed a couple of weeks ago in the MIDAS meeting in Austin. The proposed tag syntax is as follows:
<macrosyntax> ::= <tag_open> MACROSYNTAX <processor_name> <arg_list><tag_close> <processor_name>::= <alpha_numeric_id> <arg_list> ::= <arg_list> <arg> | <arg> <arg> ::= <arg_token> [<value>] <arg_token> ::= <alpha_numeric_id> <value> ::= '=' <quoted_string> <tag_open> ::= '<' <tag_close> ::= '>' <quoted_string>::= '"' <ASCII_Char*> '"'Let's assume a sequence of macro syntax specifications like:
<macrosyntax FRONTIER start="{" end="}" format="#ID OPT_ARG_LIST"> <macrosyntax NETCLOAK start="<" end=">" format="HTML_TAG" render_at="SERVER"> <macrosyntax PAGEMILL start="[[" end="]]" render_at="SAVE">The mandatory arguments to the macrosyntax tag are the processor name and the start and end values at a minimum. All other argument tokens should/could be considered macro processor-specific and would be made available to the appropriate renderer.
This tag can be included in the HTML file being rendered. Alternately, it can be used as a "predefined header" for rendering tools, or it can simply be implied because a given renderer understands specific hard-coded syntaxes.
In the example above, the first line defines the syntax for the tool supplying the "FRONTIER" set of services. In this case, the "format" specification may be tool specific or conform to some standard set of format specifiers. In any case, that data is specific to the FRONTIER service and is used by that renderer to help cue it to syntax between delimiters it owns. This allows a single tool to support multiple dialects of its own syntax, for example.
The second line is similar, but basically says that the NETCLOAK service should process all HTML-like tags, but only at the time the page is served. The "render_at" tag is strictly an example of what MIGHT get defined, since the explicit list of arguments to the <macrosyntax> tag is limited to "start" and "end".
The final line is simply a variant that shows that the PAGEMILL service is to handle all "[[ ]]" tokens and cues the renderer to only perform this operation with the file is saved.
In practice, a renderer might read a HTML file containing a sequence of these <macrosyntax> tags. At this time, the user (or appropriate settings) could be consulted to determine which physical application, internal subroutine, or plug-in was to parse and render these tags. This allows for the possibility of both a tool like Frontier that could conceivably handle all tag formats and a tool like PageMill that might invoke downstream renderers to process specific tag formats.
What this syntax DOESN'T address well is macros that are applied to blocks of plain text. Since it only specifies the start and end tokens for wrappers around a set of text, you would have to do something like the following:
<macrosyntax NETCLOAK start="<CLOAK>" end="</CLOAK>">
and repeat definitions for all the different matched set tags that NetCloak supports. The assumption here is that the renderer would have to keep some sort of symbol table that tracked all of the start/end tokens to parse for and which renderer was defined to handle them. Not a big deal, but the implication is that more than one <macrosyntax> tag could be defined for a single macro processor.
The implication here is that if a <macrosyntax> tag redefines the processor for a begin/end pair that was defined earlier in the file, that new definition would be in effect for the remainder of the file. This allows 2 renderers supporting the same macro syntax to be used for different portions of a file.
Follow-ups to mailto:mida-web@mida.org, please.
|
This page was last built with Frontier on a Macintosh on Wednesday, August 27, 1997 at 7:37:27 PM. Thanks for checking it out! Dave |