> Is a consensus now forming around the position that shoe-horning any more
> functionality into the limits of what is possible within a single attribute
> string in HTML is maybe not such a smart move?
Lou raises an important point. There has always been a tension in
these discussions between simplicity and the flexibility that enables
more complex implementations.
RFC #1 will outline the elements and the consensus on how to code
unstructured elements in HTML. This is Lou's simple case.
Nonetheless, I am still hopeful that we will be able to agree on a
single, simple mechanism for adding a qualifier to an element's
content string.
In the case of some elements, a qualifier is not very important (only
librarians, and not all of them, even, will care if an author is
constructed according to AACR2 rules). In other cases, a qualifier is
useful for proper interpretation of the field (our old friends DATE and
LANGUAGE, for example). In still others, you can't even consider doing
it without a qualifier (a DDC number or LCSH specifier, for example).
There are many ways to do this, and all of them are kludgey to one
degree or another, but be heartened by the fact that (a) these
structures can be built by software (personally, I don't even want to
type in the unstructured versions of these tags), and (b) the embedded
HTML solution is a short term jump-starting strategy that will soon be
overtaken by other infrastructural developments (PICS and WebDAV, for
example).
We need this short-term fix, but we should not lose sight of the fact
that these syntactical issues are only a means to our major goal:
defining the semanitics of the description itself.
stu
(who is getting up an hour earlier each day in preparation...
and tomorrow I start driving on left side of the road)
|