Encoded Archival Description List <[log in to unmask]>
I tend to agree with the sentiments expressed by Ricky E. Things are not
perfect, but we've got to keep working at it, with the vendors, to get our
needs met and problems resolved.
However, these recent exchanges about the SQ "evaluation" viewer plug-in
highlight the fact there never has been and continues to be no direct
communication between this list and SoftQuad. In fact, given their total
silence, one must conclude that SoftQuad does not even monitor the EAD list.
(That in itself makes one wonder ....)
It seems to me that a mechanism for communicating authoritative information
from SQ to the EAD list, and for list members to forward helpful suggestions
and concerns to SQ, is needed and long overdue. If SQ isn't taking the
initiative, wouldn't RLG be that obvious conduit? After all, RLG is
promoting the EAD initiative and (I believe) recommending, even
facilitating, the distribution of SQ products through it's FAST training
program. Is it not fair to assume, therefore, that some sort of ongoing
cooperative working relationship between RLG and SoftQuad exists, and that
it should be tapped for this purpose?
It would be a great service to the EAD list (possibly SoftQuad as well) if
RLG would assume this role. We will then be able to distinguish more readily
problems that truly *are* inherent in the current SQ products,from those
that are influenced by local circumstances or past (now obsolete) experience?
Manuscript Unit Head
Beinecke Rare Book and Manuscript Library
At 11:41 AM 6/11/97 PDT, you wrote:
>REPLY TO 06/11/97 08:56 FROM [log in to unmask] "Encoded Archival Description List":
>I think that we professional information providers have to accept our
>role at the bleeding edge. It would be a shame to bring things down
>to the lowest-common-denominator level (though I think offering
>alternatives for access is best). There is so much advantage in
>using SGML -- for retrieval, for navigation, for cross-platform use,
>and for the creation of a single document that can be output for
>computer display, print, non-Web use, braille, etc. If we don't push
>the envelope who will?
>In general, the implementation of SGML has been very focused to
>specific, often off-line, applications. Development of tools to
>access SGML-encoded information on the Web (in all its varied
>instances) is difficult and there is not enough market to drive the
>development of a lot of tools (especially in the environment where
>everyone expects free tools!). I think we should be grateful for
>what SoftQuad has done, imperfect though it may be, and keep pushing
>for more and better tools. Meanwhile, we should follow the
>development of XML as it may bring our applications into a mainstream
>where browsers can handle them without helper apps and plugins.
>To: [log in to unmask]