From fadushin@syr.edu  Mon Dec 18 14:25:15 2000
Received: from mailroom.ecs.syr.edu (ecs.syr.edu [128.230.208.14])
	by swi.psy.uva.nl (8.9.3/8.9.3) with ESMTP id OAA10776
	for <prolog@swi.psy.uva.nl>; Mon, 18 Dec 2000 14:25:14 +0100 (MET)
Received: from apollo.ecs.syr.edu (apollo.ecs.syr.edu [128.230.208.46])
	by mailroom.ecs.syr.edu (8.10.2/8.10.2) with ESMTP id eBIDPdY20129
	for <prolog@swi.psy.uva.nl>; Mon, 18 Dec 2000 08:25:39 -0500 (EST)
Date: Mon, 18 Dec 2000 08:25:39 -0500 (EST)
From: Fred Dushin <fadushin@syr.edu>
X-Sender: fadushin@apollo.ecs.syr.edu
Reply-To: fadushin@syr.edu
To: SWI Prolog <prolog@swi.psy.uva.nl>
Subject: Re: swi jpl character coding
Message-ID: <Pine.SOL.4.10.10012180807290.10795-100000@apollo.ecs.syr.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

// > One problem might be the textual
// > representation of atoms containing illegal UTF-8 sequences.  It whould
// > be nice if write_canonical and read can deal with *any* Prolog term.
// 
// [including floats, and cyclic and recombinant terms please! :-]
// 
// > Assuming UTF-8 you could make the atom start with an illegal sequence
// > and add a foreign routine to return its type.
// 
// OK, that's neat: let's have UTF-8 for textual names, hooks for optional
// custom handling of non-UTF-8 atoms (with some default catch-all handling).
// 
// NB is there some de facto standard type system we should be using, e.g.
// those MIME type thingies?

Ugh.  No MIME, please.  It has i) ugly syntax, and ii) no semantics.
Better we just roll our own, I think.

In CORBA Security, we use an opaque field (sequence<octet>) of a
particular data structure to be an OID, representing an authority
that defines the encoding of the data that is the kernel of the
data structure in question (a security attribute, in this case).
If this field is empty (byte[0], under the Java mapping), the
"defining authority" is the OMG, and the encoding, by default, is
UTF-8.  That way, you can define a security attribute any way
you like (e.g., fingerprint, retinal scan, etc.)

I think any extensible data structure would work for our purposes.
The question is how or whether we want to deal with interoperability
and portability across what we might call "encoding domains".

-Fred

-- 
Fred Dushin <fadushin@syr.edu>

vi rulse!^H^H^Hes!
`:wq

