>>>>> On Sun, 23 Feb 97 16:19:12 EST, [log in to unmask] said:
Lee> Jon Knight <[log in to unmask]> wrote:
Jon> Misha Wolf <[log in to unmask]> wrote:
Misha> [...]
Misha> <META NAME = "DC.publisher.name" CONTENT = "I think it is
Misha> "Bloggs & Bloggs" but I need to check this)">
Jon> Wow, a blast from the past. :-) When we were originially
Jon> discussing qualifiers back in the dim distant past, this was known
Jon> as the "dot kludge" approach
I had forgotten this but have been thinking about the issues...
Lee> Actually there is a way of looking at this as not being a
Lee> kludge, and I still favour it. One problem is if you have a
Lee> scheme whose character set can't go in an SGML name -- no SGML
Lee> qoting is possible in the NAME part, although one could adopt a
Lee> convention, like %dd except that % isn't allowed.
If we really went down this road (but see later) the only characters
allowed in a META NAME (I think) from the SGML header for the
HTML 3.2 DTD are: A-Z a-z 0-9, - and .
Hence there is very little scope for creating something that is
readable, validates and can encode stuff. You may end up using
'-'+hex digits to escape characters when a qualifier value contains
any character outside of A-Z a-z 0-9 e.g the well known fake example:
Element Date with value 19970223
Qualifier name Scheme, qualifier value "ISO.1234(1996)"
gives:
<META NAME="dc.Date.Scheme.ISO-2E1234-281996-29" CONTENT="19970223">
Loose: Clarity, ease of use. However, you may think this does not
matter IF we assume only programs write DC in HTML since
making users do the above is rather hopeful -- special
encoding should be rare, not common.
Gain: Content now just holds element value.
I think this fails the 'simplicity' check for DC.
Lee> Personally I'd like to use something like
Lee> NAME="dc.publisher.name/BCIP-1996"
Lee> where BCIP-1996 is the naming authority responsible for the field/scheme
Lee> called "name".
We cannot use '/' in NAME (I think) as I said above.
Lee> Another way would be to be able to reference a "profile" or
Lee> registry in which all your shceme names were defined:
Lee>
Lee> <META NAME="dc.scheme.bciom"
Lee> URL="http://where/you/can/get/a/definition/of/the/profile"
Lee> CONTENT="BSI:12008-1997, British Cataloguing in Online Media"
Lee> >
Lee> where the CONTENT identifies a hypothetical standard to which
Lee> all the given schemes relate, and CONTENT is a title or
Lee> identifying name.
... and URL breaks HTML since it isn't an attribute of META.
However, registering schemes / registries for qualifier values is
probably a good idea hence the style of hierarchical qualifier values
that we have proposed using of the form <registry>.<standard> e.g.
"ISO.xxxx" and "IETF.xxx" so new standards can be easily leveraged
into qualifier values -- I think this is a Good Thing.
(However using the NAME encoding above we couldn't do this without
escapes).
Lee> Now, I could say
Lee> <META NAME="dc.publisher.bciom.address"
Lee> CONTENT="Haynes Vicarage, Haynes, Beds MK45 3QP">
Lee> <META NAME="dc.publisher.oclc.address"
Lee> CONTENT="http://www.vicarage-books.co.uk">
Lee>
Lee> Search engines who don't care about the extra precision can
Lee> index all the publisher fields as "publisher"; others can have
Lee> the precision.
Lee>
Lee> I was hoping to write this up earlier, but am still mulling over
Lee> details.
Now the problem with this is that what happens when I don't want to
have a scheme, or scheme is unknown? In that case do I have to leave
a gap? ie. does
dc.publisher.scheme.scheme-value.<MORE>
become:
dc.publisher...<MORE>
That seems particularly obtuse (especially if skipping many
'required' qualifiers).
In fact, having any requirement on qualifiers is going to fail.
Like elements, qualifiers used should be entirely optional - you can
put whatever qualifiers you want (including none).
Dave
|