On 29-May-07, at 2:33 AM, Claus Färber wrote: > Johnny Bufu schrieb: >> The attribute metadata can be used to define attribute-specific >> encodings, which should deal with issues like this. > > Ah, so the _usual_ way is that the metadata (Can this be renamed to > "datatype definition"? "metadata" is very misleading.) defines the > encoding.
That would be the preferred way, yes. "Metadata" seems to make sense to most people involved in the schema effort, because it can contain other stuff beside data type description. But this is a work in progress, so if you're interested and want to make your case I'm sure you'll be most welcome on the idschema list: [EMAIL PROTECTED] http://mail.idcommons.net/cgi-bin/mailman/listinfo/idschemas > For binary data, it will be base64Binary or hexBinary as > defined in XML schema. Correct? Yes, whatever encoding is defined in the metadata document. >> The AX protocol has to stay simple (that was overwhelming feedback >> I've received at IIW). The base64 encoding is there as a convenience: >> if a number of OPs and RPs agree on an attribute type (the classical >> example being an avatar image) but don't want to go to the trouble of >> publishing metadata information, > > In other words: The metadata is implicitly agreed upon by the parties > involved. If they can agree on the meaning and the base format > (integer, > string, *binary,...) they can also agree on an encoding (e.g. agree on > base64Binary instead of *binary). > > So I don't think AX needs means to flag base64 data. The parties > involved should know when base64Binary or hexBinary is used by out of > band information (metadata/datatype definition or mutual agreement). I see your point - if the parties involved agree on the attribute type and (implicitly) on its data format, they can / should go one step further and agree on the encoding as well. And eventually the prevailing method would be to programatically determine the encoding from the metadata documents. > In other words, AX should just restrict values to UTF-8 strings and > recommend base64Binary (or hexBinary) for datatypes (datatypes, not > data!) that can't be represented as UTF-8 strings. Yes, that would work too; it would be basically AX draft-5 plus disallowing newlines in attribute values in order to comply with the underlying OpenID data formats. If there's agreement that encoding is more tightly coupled with the attribute types and their metadata definition, we can just reference that in the AX spec. Johnny _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs