W3C home > Mailing lists > Public > uri@w3.org > January 1995

Re: Library Standards and URIs

From: Terry Allen <terry@ora.com>
Date: Tue, 3 Jan 1995 13:09:19 PST
Message-Id: <199501032109.NAA21261@rock>
To: Larry Masinter <masinter@parc.xerox.com>, rdaniel@acl.lanl.gov
Cc: uri@bunyip.com
| We can't eliminate the chaos that already exists in the world of
| meta-data for documents; trying to invent a 'core' set doesn't reduce
| the chaos, in fact, but rather adds to it, by introducing yet another
| *new* attribute set.

Not chaos, but variability.  Anyway,

| Naming each attribute *set* rather than each individual attribute will
| reduce the length to be something managable. It might be possible to
| also allow individual attributes to be named even if they don't occur
| in the overall set.
| <urc scheme="urn:iana:here.there.org:foo">
| <author>...</author>
| <title>...</title>
| <author scheme="urn:iana:banana.br:trigram">
| </author>
| </urc>

This example seems to mix one overall scheme (here...) with
a scheme local to an individual element (banana...).  Wouldn't
it be better to offer instead only a choice of overall schemes,
on the assumption that the components are defined by the overall

If that's to be done in SGML (which I am not advocating), schemes
with different URCs will have different allowable contents.  It is
one of SGML's weaknesses that attributes can't affect content
models (you can't say in the DTD that <urc scheme="foo"> shall
contain only those elements allowed by scheme foo).  So a better
approach (if SGML is really desired) would be to have one element
for each flavor of URC:  urc.foo, urc.here, urc.banana.  Then
in the DTD one could require that urc.foo have only the 
desired content.

Terry Allen  (terry@ora.com)   O'Reilly & Associates, Inc.
Editor, Digital Media Group    103A Morris St.
			       Sebastopol, Calif., 95472
A Davenport Group sponsor.  For information on the Davenport 
  Group see ftp://ftp.ora.com/pub/davenport/README.html
	or  http://www.ora.com/davenport/README.html
Received on Tuesday, 3 January 1995 16:11:32 UTC

This archive was generated by hypermail 2.4.0 : Sunday, 10 October 2021 22:17:29 UTC