-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Werner,
> please note I'm talking about the 'response' to a request [1] : > these are not properties as such in the DDR but properties to be > added to the response from a DDR, and thus should be defined. > >> So you mean the "client" not the data here...? I'm talking about the version information as per W3G specifications : http://www.w3.org/TR/DDR-Simple-API/#sec-Service-getDataVersion : "Returns information about the underlying data (values for Properties) if the implementation has a versioning system for that information. If it does have a versioning system for data then this value must change between calls if the implementation can not guarantee that the data is the same. If the implementation does not have a versioning system, the value __NOT_SUPPORTED" DeviceMap supports versioning, ergo...when you send out a json or whatever response, the versioning meta-data and DDR identifiers are added, as per specs and for simple sanity :-) > > >> I'm very aware of e.g. the UUID class in Java, but some of that >> seems to be mixing up the actual device repository with session >> information. Entries now have an id that shall be unique within >> an entity like "Device", e.g. id="SAMSUNG-SGH-i780" What value >> would a "guid" field add here? The semi-human readable ID seems >> OK, why do we need another one? > >> I think where entirely new structures are what you have in mind, >> it is better to draft actual pseudocode in the Wiki or a similar >> document, that is easier to see where each attribute is intended >> to be used than just by mail. This has nothing to do with session. The point is that, as you point out, the Device and its [current] property set, have a unique id. The current device Id, like the one you mention : "SAMSUNG-SGH-i780" in no way guarantees uniqueness [is this case-sensitive ? what about non-Latin characters ? what's 'valid' ? max length ?...].[1] Something like a guid, on the other hand, by its very nature, guarantees that. Keep the current Id as is, add a 'guid', when in doubt : follow the guide. Who generates guids how and where is not relevant, what is is that once released in the DeviceMap data, it may disappear [deleted] but it will *never* change. This way the TimeStamp and DDR response-properties meet the W3C specs and the guaranteed unique 'token' allows you to put 'same' responses in context for testing, quality control and data validation. Again, all this is mainly in the context of a DDR request/response, i.e. : meta-data the API adds to it's response : version of the data and a guaranteed unique identifier of the dataset [replication !!]. esjr. [1] do a case-sensitive search vs a non-case sensitive one ;-) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJT+mzSAAoJEOxywXcFLKYcIMwH/AjHB2qZG7LR+oL/Afq5TKmj OVks1nkcMZk9i3oUcKwv3dcd/wwMpwNqd9DcU6LEbxer46dAkBXkLcdecW0yOTH3 u3BnyTj0YMK+luOMg7F/6tUmXvZ0Q8I5Sw+GkzsYt6b6jIqaUfiERO8fuxLotgyu 0JQNpmgNTXhJwa5Y+bEbRY4GAZ5fOKZRf9llDso3jacqeXsuCHLcV+wtM/LmZDCn p6E0bcQL35L7QqkgdzSppCSyEZ/MjO37LAmMDZwCYA+fdlX+i+eK/AXQ3D5xH6pO HKEAHVqAiFe5Xf0KVJfIUmuZyf74HMQ0QxLvWLzoHz72E3HI8sIqx7YEL/btGUo= =U4Zv -----END PGP SIGNATURE-----
