> [Ed Summers said]
> > Michael -- there is a nice side effect of running your SMGL through
> James
> > Clark's SX (the SGML->XML converter that you mentioned
> >, in that external entitites are expanded
> using a
> > catalog.  The resulting XML file isn't exactly pretty since it has oddly
> > placed line breaks--but (of course) it is valid XML!
        [Pete Johnson Replied] ....

> I think one of Michael's points was that XSLT doesn't provide a
> mechanism to _access_ the value of that system identifier during a
> transformation, so using XSLT, one can't transform from an EAD
> element with an entityref attribute pointing to an unparsed external
> entity, like
> <extref entityref="myentity">
> to an HTML
> <a href="">
> even if SX _has_  generously provided
> "" as a system
> identifier in an entity declaration for myentity.

In a round-about way, style sheet mechanisms may help to provide some of the
desired functionality of the SGML catalog for the XML world, at least
insofar as locally managed resources go.

In the example above, we would encode the EAD link as
<extref href="myentity.sgm"/>

One can assuming that such file names are not likely to change (any more
than an entity name would at least).  It is the balance of the system

the path to a file name (../../SomeFileLocation/)      or

a url ( ),

that is apt to change over time.   This part we supply through the
stylesheet.   If the file structure or naming conventions change, we merely
alter the information in one place, the stylesheet, and the href outputs are
adjusted accordingly.

This replicates the change-one, alter-many concept that lies behind both
stylesheets and file resolvers such the SGML catalog, purls, and file
handlers.   Of course, the scope of this "solution" is limited to files we
control locally but then that is pretty much true of entities as well.

> Moving slightly beyond the domain of EAD, I was interested by David
> Durand's suggestion that XML's ease of use makes it a better
> candidate than SGML for an archival format. As a community with a
> particular interest in finding formats with longevity - not just for
> our finding aids, but for digital documents in general -, we should
> seek support in XML and XML tools for features which enhance that
> longevity - particularly if, as David suggests, one of the principal
> barriers is that vendors are not being made aware of the demand!
> Having said that, of course, I am aware of the danger of asking for
> the re-introduction of the very complexity which XML was intended to
> avoid.....
Just look at Dublin Core where the same unresolved tension exists.

> Michael
> Michael Fox
> Head of Processing
> Minnesota Historical Society
> 345 Kellogg Blvd West
> St. Paul MN 55102-1906
> phone: 651-296-1014
> fax:  651-296-9961
> [log in to unmask]