On Mon, Aug 25, 2014 at 12:53 AM, eberhard speer jr. <[email protected]> wrote:
> -----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 : > > That's the version of the API and data, but not one for each line. OpenDDR previously returned a pre-defined constant which may change (e.g. "2012") but reading the XML file should not be a problem either. However, there seems no sense, neither does the Service interface make any intention that the data version changed on a line by line basis. If e.g. The new Java API allows to access multiple data sources, then getDataVersion() may return different values depending on what source you call, but the API version only depends on the actual version of the library. > "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----- >
