OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xdi message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Native-datatype implementation/conformance questions


I took an item in the July 1 teleconference we just finished to start a thread on these issues. Instead of considering JSON (or other serialization format) native type system just as one means of expressing a priori XDI type information, this is focused on problems that the native type systems may pose for users (i.e. application developers) and implementers of XDI APIs. Off the top of my head to start:

If we use only JSON's string type to represent all XDI literals:
- Should we accept JSON with numeric, boolean etc. values, or throw a parsing error?

If we use JSON native datatypes:
- Are all JSON types usable in XDI JSON? For example, if we use JSON arrays to represent XDI contexts, or use JSON null, does this mean some JSON data are not representable?
- Are there some JSON types we specifically do not want to support?
- Will data of all types be unchanged and have the same type after round trip conversion?
- How do the JSON types (or subset we allow) compare to other type systems? (in either other serialization protocols or programming languages that are likely to be used)

Efficiency arguments:
- Will using JSON native types have any significant effect on performance?

smime.p7s



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]