-----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, yes, the data is included in the XML header, but should be transmitted in the response to a request [2]. I also forgot to mention the most obvious : timestamp : ISO 8601 UTC time stamp when the response was generated. GUID : it is a common concept in the industry and the point is *not* for anyone to generate them -- allthough, I'll gladly explain how it's done in java ;-) The point is : replication instead of duplication. And yes, I do have them in 'my' existing data, I fail to see the point, unless of course it pertains to 'your' data... And if a guid is oh so upsetting, I'm open to any [industry 'standard', cross-platform] method you propose to ensure that a response has a constant 'globally' unique id that will not change while the rest of the data around it might, and will change. esjr [1] http://www.w3.org/TR/DDR-Simple-API/#sec-Service-query-methods [2] http://www.w3.org/TR/DDR-Simple-API/#sec-Service-getDataVersion [3] http://www.w3.org/TR/NOTE-datetime On 24/08/2014 21:09, Werner Keil wrote: > On Sun, Aug 24, 2014 at 7:29 PM, eberhard speer jr. > <[email protected]> wrote: > > Hi, > > since we're adding anyway ;-) here are some more 'new' properties > I'd like to propose : > > ddr_ : properties pertaining to the DDR responsible for the > 'response' > > ddr_vocabulary : Vocabulary Name [example : DeviceMap] ddr_api : > version number of the API used to create the response ddr_version : > data resources version number ddr_date : release data of the data > referenced in version number > > > > >> I suppose these are mostly for the header (where they are already >> more or less maintained right now) or would you put a version of >> the resource data with every single device entry? The >> "ddr_vocabulary" sort of exists, it was added by OpenDDR and I >> think it's called "from" or similar. That contains values like >> "ODDR" or (if we add new ones) "DeviceMap". > >> I don't think it is very heavily referred to, mostly meta-data, >> so if it makes sense for better understanding such a field could >> be named differently, e.g. ddr_vocabulary, too. > > > > > guid : a *unique* identifier use-case : user queries DDR, gets a > response, [user may save the response], later user re-queries the > DDR and gets a *different* response. The guid tells the user both > are responses to the same request, when properties [or their > number] change over time. > > >> Do you have all of these in your existing data, too? E.g. where >> would we generate such guid (which except a few cases is a rather >> MS/.NET feature btw;-) > >> Most others I don't see the "use-case" of these, they sound >> fairly dynamic, e.g. for a particular session. That is nothing a >> single device "class" would hold, would it? > >> Maybe you can explain these 3 a bit more. > >> Thanks Werner > > > > Comments ? > > esjr >> > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJT+lBkAAoJEOxywXcFLKYcqEwIAIdF+j28oJY3higpyHcKbjgd NuKmlc+qUqlGfOEm6QCCAQjPWLvbhZBYUS5YA6/OQ/gd+qCbOxkCy2FPDlpYLTCA 993CjmTk71kUS2+4YjeZ98dMUr6NldIgBd+vi32sbaBJbRcmF7AoyslpAxq7j+nR 7XkJ2Pfkql4+Km17LGEs/VveCyOwIgGLrxf8lhCLsA80jcqArEbYdS2Mpo8+aILs McTesvgX0vFLYnGEiChoKNy66zWyr/OI7MtP0Y1AYpccDBsasNoC+ILpESDNGD5r T51SfBK46jzyQ8YUWlmqoZ4fhVFMpBSaCOZYpA6Bj0tU5NxJY6/rXDT2rL4Yk3s= =8viV -----END PGP SIGNATURE-----
