Date: 13 Jul 94 08:32:55+0200
From: pays@faugeres.inria.fr
To: ccoprmm@oit.gatech.edu, masinter@parc.xerox.com
Subject: Re: New URC Specification is ready....
Message-Id: <774081175.6059.0-faugeres.inria.fr*@MHS>
>
> > You got any suggestions?
>
> I think there are two choices (someone correct me if there are more):
>
> 1) the URC is a document, and, as such, is encoded in a character set.
>
> Content-type: text/urc; charset=US_ASCII
>
> Author: Masinter, Larry
I basicaly agree that URC is a document but I remeber clearly than
part of the group insist on a URC being just a collection of
information coming possibly from different sources (location)
thus the definition of URC is needed prior to answering that question
anyhow,
>
> 2) each attribute value is (possibly) a document, and needs a way to
> encode it within the URC.
this absolutely REQUIRED whatever the answer to the previous question.
If you allow any URC to be encoded in its own char-set it will be
extremely uneasy if not impossible to search based on attribute values
(specialy approximate search).
On the other hand, at least for Author and Title it is mandatory to
have at least one of the alternate values being represented in
an appropriate char-set to give an EXACT value.
As I suggested before
1. the char-set must be specified for each attribute value
a possible default being US-ASCII
2. Attribute such as Title or Author must be multi valued when not
in US-ASCII and that international access is to be provided.
A flag is required to distinguish the "official value" from
the "provided for search" transcriptions
3. It is mandatory to distinguish between the different
transcriptions of a given value, and other values of a given
attributes (eg. Zurich, Zuerich, .. and Berlin)
The easiest solution would be to make each attribute value a MIME
document (that would solve many issues such as transport syntax
etc...)
However this is a very very hammer for these simple things,
I suggest a MIME-compatible rep of char-set and encoding
at attribute level, without making a full MIME document of each
attribute.
This will of course complexify this URC specification, but
without an adequate solution to the char-set problem the URC
will remain a english-US solution and expect X.open or Microsoft
to fill the hole with their own specs
-- PAP
>
> I don't actually understand how to accomplish 2 if URCs are also
> expected to be `transport friendly', i.e., themselves included in
> text/plain; charset=US_ASCII messages.
>
>