Re: Parameterized entities?

FWIW, SGML has data attributes ie attributes declared on notations, and then defined in declarations of entities having those notations, such as

    <!NOTATION gif SYSTEM>
    <!ATTLIST #NOTATION gif
       width NUMBER #IMPLIED
       height NUMBER #IMPLIED>
    <!ENTITY mypic
      SYSTEM mypic.gif
      NDATA gif [ width=200 height=100 ]
      >

And while data entities can't be expanded in markup text, this mechanism can be used nevertheless for parametric macro expansion. In sgmljs.net, if the notation has or is derived from the public identifier for SGML, and is used/redefined in a link type, and used as eg #CONREF entity (ie not as entity reference but as value of an ENTITY attribute, though there are more powerful alternatives), this gives you a fully type-checked parametric macro expansion system called templating in sgmljs.net, where the "parameters"/data attribute values appear as predefined ("system specific") entities in the template document, the document element of the template must match (or is inferred from) the element on which the template entity is placed in the invocation context, and effective markup declarations are inherited and validated into the template processing context such that the result document is guaranteed to be parseable using the main (or effective output DTD when different from the base DTD in a pipeline of link processes).

There's even a standards-defined way to pickup data attributes from regular markup attributes rather than from ENTITY declarations and perform all kinds of ninja processing using HyTime DAFE, and it's fully supported by sgmljs.net SGML.

Ok I guess I put you XML heads are already well outside your comfort zone ;) but anyway if you want to read about the details with examples, and check it out yourself, see http://sgmljs.net/docs/templating.html .

Have fun,
Marcus
sgml.io

> Am 16.06.2022 um 14:21 schrieb Roger L Costello <[email protected]>:
> 
> 
> Thank you David. It is a shame XML doesn’t support parameterized ENTITY’s.
>  
> I decided to write a simple preprocessor using the Flex lexical analyzer.  It converts the following “fake” ENTITY references:
>  
>     &file('ARPT.XML');
>     &file('NAV.XML');
>     &file('TRM.XML');
>  
> into these XSLT variable declarations:
>  
>     <xsl:variable name='ARPT.XML' select="doc('ARPT.XML')"/>
>     <xsl:variable name='NAV.XML' select="doc('NAV.XML')"/>
>     <xsl:variable name='TRM.XML' select="doc('TRM.XML')"/>
>  
> For those interested, the Flex lexical analyzer that I created is shown below. Here’s how I run it from a command line:
>  
> more sample.xsl | preprocess > result.xsl
>  
> Here is the preprocessor (Flex lexical analyzer). I am sure that a skilled C programmer could write much better C code (the stuff within braces below) to extract the filename. If you are a skilled C programmer and have suggestions for improvement, I would love to hear them!
>  
> %option noyywrap
> %{
> #include <string.h>
> %}
> %%
> "&file('"[A-Z]+".XML');"           {
>                                                            char replacement[20];
>                                                            char *start = strstr(yytext, "'");
>                                                            char *end   = strstr(yytext, ".");
>                                                            int length = end - start - 1;
>                                                            char *marker = start + 1;
>                                                            int i;
>                                                            for (i=0; i<length; i++)
>                                                               replacement[i] = *marker++;
>                                                            replacement[i]    = '\0';
>                                                            fprintf(stdout, "<xsl:variable name='%s.XML' select=\"doc('%s.XML')\"/>", replacement, replacement);
>                                }
> %%
> int main()
> {yylex();}