<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<?xml-stylesheet type="text/css"
   href="/~hammond/style/gellmuart.css"?>
<!DOCTYPE article
  PUBLIC "-//GNU GPL: William F. Hammond//DTD GELLMU XML 0.7.5L//EN"
  "http://www.albany.edu/~hammond/gellmu/xml/axgellmu.dtd">
<article stem="anchors"
><preamble
><baseloc
>http:<sol mml="mo"
/><sol mml="mo"
/>www.albany.edu<sol mml="mo"
/><tld
/>hammond<sol mml="mo"
/>gellmu<sol mml="mo"
/></baseloc><surtitle
>The GELLMU Archive</surtitle><title
>The Anchor Command <quostr
>anch</quostr></title><compacttitle
/><nul
/><nul
/><nul
/><nul
/><nobaseprint
/><nobanner
/></preamble><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><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 mml="mo"
/><sol mml="mo"
/>www<per
/>w3<per
/>org<sol mml="mo"
/><quo
/><rsb
/><lbr
/>this<spc
/>anchor<rbr
/></nln></verblist>
The markup is used here for
<anch
><anchref
>href="http:<sol mml="mo"
/><sol mml="mo"
/>www.w3.org<sol mml="mo"
/>"</anchref><anchv
>this anchor</anchv></anch><eos
/></parb><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 mml="mo"
/><sol mml="mo"
/>www.w3.org<sol mml="mo"
/></urlanch><hsp
/>.</display></parb><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
><anchref
>href="http:<sol mml="mo"
/><sol mml="mo"
/>www.w3.org<sol mml="mo"
/>"</anchref><anchv
><path
>http:<sol mml="mo"
/><sol mml="mo"
/>www.w3.org<sol mml="mo"
/></path></anchv></anch><hsp
/>.</display></parb><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><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><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
><itemlabel
><label series="ita"
>macros</label>(<series type="a"
><evalref
><popkey
/></evalref></series>)</itemlabel><itembody
>Using macros such as <emph
>newcommand</emph> for <abbr
>SGML</abbr> generation<eos
/></itembody></item><item
><itemlabel
><label series="ita"
>formatters</label>(<series type="a"
><evalref
><popkey
/></evalref></series>)</itemlabel><itembody
>Carefully crafting formatters from one<apos
/>s document
                  type to <latex
/><eos
/></itembody></item><item
><itemlabel
><label series="ita"
>packages</label>(<series type="a"
><evalref
><popkey
/></evalref></series>)</itemlabel><itembody
>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></itembody></item></menu>
</parb></body></article>
