<!-- \nul; -->
<!DOCTYPE article SYSTEM "gellmu.dtd"><article stem="anchors">
<baseloc>http:<sol/><sol/>www.albany.edu<sol/><tld/>hammond<sol/>gellmu<sol/></baseloc>
<surtitle>The GELLMU Archive</surtitle>
<title>The Anchor Command <quostr>anch</quostr></title>
<compacttitle>
<nul/>
<nul/>
<nul/>
<nul/>
<nobaseprint>
<nobanner>
<body>
<parb>
The didactic <abbr>GELLMU</abbr> production system provides a command
<qquostr><bsl/>anch</qquostr> for anchors that is parallel to the <abbr>HTML</abbr> anchor
tag <qquostr><ltc/>a<gtc/></qquostr><eos/>
<parb>
An example of basic usage is given by the following markup for an
anchor to the World Wide Web Consortium (W3C):
<verblist>
<nln><bsl/>anch<lsb/>href<eqc/><quo/>http<cln/><sol/><sol/>www<per/>w3<per/>org<sol/><quo/><rsb/><lbr/>this<spc/>anchor<rbr/></nln>
</verblist>
The markup is used here for
<anch><op0>href="http:<sol/><sol/>www.w3.org<sol/>"</op0><ag0>this anchor</ag0></anch><eos/>
<parb>
The <emph>urlanch</emph> command provides a succinct way to insert
an anchor whose visible content is the referenced <abbr>URI</abbr>.<footnote>
The name <emph>urianch</emph> would be more <quophrase>correct</quophrase> since its
content is a <abbr>URI</abbr>.</footnote>
Either of these commands may be used in a display, as here:
<display><urlanch>http:<sol/><sol/>www.w3.org<sol/></urlanch><hsp/>.</display>
<parb>
One may ask whether there is a difference between the use of
a macro <emph>Urlanch</emph> defined by
<nul/>
<display><quostr><bsl/>newcommand<lbr/><bsl/>Urlanch<rbr/><lsb/>1<rsb/><lbr/><bsl/>anch<lsb/>href<eqc/><quo/><hsh/>1<quo/><rsb/><lbr/><bsl/>path<lbr/><hsh/>1<rbr/><rbr/><rbr/></quostr></display>
and <emph>urlanch</emph><eos/>  The latter is used here:
<display><anch><op0>href="http:<sol/><sol/>www.w3.org<sol/>"</op0><ag0><path>http:<sol/><sol/>www.w3.org<sol/></path></ag0><hsp/>.</display>
<parb>
There <emph>is</emph> a difference<eos/>  The command <emph>urlanch</emph> corresponds
to an <abbr>SGML</abbr> element, while anything defined with <emph>newcommand</emph>
is fully expanded by the <abbr>GELLMU</abbr> syntactic translator before
<abbr>SGML</abbr> generation<eos/>  This means that the treatment of <emph>urlanch</emph>
by a formatter is completely independent of the treatment of <emph>anch</emph>
and <emph>path</emph> by a formatter, while the treatment of <emph>Urlanch</emph>,
if so defined, is entirely dependent on the formatter<apos/>s treatment of the
other two names<eos/>
<parb>
Whether it is sensible to undertake the effort of coding formatters
to handle the <abbr>SGML</abbr> element <emph>urlanch</emph> in addition to the
<abbr>SGML</abbr> elements <emph>anch</emph> and <emph>path</emph> depends upon whether
or not one imagines that there is at least one hypothetical output
format for one<apos/>s document type that might benefit from independent
treatment.<footnote>
With the default <abbr>GELLMU</abbr> formatter for <latex/>, for example, a
footnote is created with <emph>Urlanch</emph> but not with <emph>urlanch</emph><eos/>
(A footnote might also be avoided by using a different attribute name
<emph>Href</emph> instead of <emph>href</emph>, but that still does not make the
issue vanish.)
</footnote>
<parb>
If one thinks about these issues solely in terms of formatting from
<abbr>GELLMU</abbr> markup to <latex/>, one will come to realize that
there are several approaches to the needs traditionally met in
the <latex/> world with packages:
<nul/>
<nul/>
<nul/>
<menu>
<item><op0><label series="ita">macros</label>(<series type="a"><evalref><popkey></evalref></series>)</op0>Using macros such as <emph>newcommand</emph> for <abbr>SGML</abbr> generation<eos/>
<item><op0><label series="ita">formatters</label>(<series type="a"><evalref><popkey></evalref></series>)</op0>Carefully crafting formatters from one<apos/>s document
                  type to <latex/><eos/>
<item><op0><label series="ita">packages</label>(<series type="a"><evalref><popkey></evalref></series>)</op0>Writing <latex/> packages to <quophrase>receive</quophrase> various
               <abbr>SGML</abbr> (or <abbr>XML</abbr>, of course) document types.<footnote>
In fact, it is generally easier to write formatters for document types
that are formally <abbr>XML</abbr><eos/>  On the other hand, writing <abbr>SGML</abbr> is easier for
authors<eos/>  Since an <abbr>SGML</abbr> parser can, for most document types, convert
<abbr>SGML</abbr> to <abbr>XML</abbr>, it is sensible for document types used with <abbr>GELLMU</abbr> to
have both <abbr>SGML</abbr> and <abbr>XML</abbr> definitions.</footnote>
</menu>

</body>
</article><!-- GELLMU version 0.7.4.4 (03-Jun-2007) -->

