# Re: Library Standards and URIs

Ronald E. Daniel (rdaniel@acl.lanl.gov)
Mon, 2 Jan 1995 10:03:31 -0700

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Paul Hoffman: "Predraft of a new URL scheme: mailmsg"
- Previous message: Ronald E. Daniel: "Re: Library Standards and URIs"
- Maybe in reply to: weibel@oclc.org: "Library Standards and URIs"
- Next in thread: Ronald E. Daniel: "Re: Library Standards and URIs"

    From: "Ronald E. Daniel" <rdaniel@acl.lanl.gov>

    Date: Mon, 2 Jan 1995 10:03:31 -0700

    Message-Id: <199501021703.KAA06540@collie.acl.lanl.gov>

    To: terry@ora.com

    Subject: Re: Library Standards and URIs

Terry Allen sez:
> I catted together the fragments from
> http://www.acl.lanl.gov/URI/SGML/
> to get the following DTD. It has a few bugs, noted in comments.

Thanks for taking the trouble to do this. I hadn't really thought that
the fragments were close enough to completion to try and combine them,
but your effort should help push things along. Sorry for the bugs, but
then I haven't even finished reading the "Gentle Intro to SGML".

> Regarding the choice of elements, I have to print out and read through
> your docs; you know I object to Review; and I think Author needs more
> detail (if only SORTNAME, e.g., Terry <sortname>Allen</sortname>).

The review attribute may be something that members of the group just
have to agree to disagree upon. While you object to it, others at the San
Jose IETF said they really wanted to see such an attribute in the URC.
Given that we are going to be capable of putting anything into a URC,
there is no way to keep out reviews (aka SOAPs). How about a compromise of:
1) Following Stu's suggestion of having different URC attribute sets (which
may fall into simple levels, or may have a more complex relationship).
2) Not having <review> in the simplest set of attributes, which ALL code
that claims to do anything with URCs will have to understand.
3) Going ahead and standardizing the syntax and semantics of <review> in an
additional set of attributes?

As for Author, I was thinking that we would adopt the AACR2 rules of
listing an author's name in the form that it normally appears in sorted
lists of names for the author's culture. For most of the people on this
list, that means "Last, First [MN | MI.] [GQ]". I am willing to be
convinced about the need to provide a <sortname> attribute, but it is
yet another step away from a simple URC. Besides, identifying only one
sortname leaves us with the task of deciding how to manage the
collisions - we would still have to know that first names are more
significant than middle names, which are more significant than
generational qualifiers. We would also have to know how to infer these.
For those reasons it seems better to adopt a standard convention.

> The use of
> <!ELEMENT authorname O O (#PCDATA)>
> is a clever way of evading "mixed content," which creates problems
> with newlines, but it is the sort of trick that has been deprecated
> (along with ALL tag omission) as making it harder to construct
> special-purpose parsers for SGML-encoded content.

The reasons for that trick are mentioned in
<URL:http://www.acl.lanl.gov/URI/SGML/>, but using it could certainly make
it harder to develop a minimal URC parser. Perhaps others in the
group will offer their opinons on the tradeoff between ease of entering
simple URCs and ease of building parsers.

> This is a nice step forward, and I'll be looking at it next week,
> after MORE FOOTBALL.

Thanks for the compliment, and for putting in some work to push this forward.
Talk to you later,

Ron

- Next message: Paul Hoffman: "Predraft of a new URL scheme: mailmsg"
- Previous message: Ronald E. Daniel: "Re: Library Standards and URIs"
- Maybe in reply to: weibel@oclc.org: "Library Standards and URIs"
- Next in thread: Ronald E. Daniel: "Re: Library Standards and URIs"