Mailing-List: contact dev-help@devicemap.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@devicemap.apache.org
Received-SPF: pass (nike.apache.org: domain of werner.keil@gmail.com
 designates 209.85.214.177 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAAGawe0bQD8UQ1iYOLF+cNMS+ESR9JkyeEotdgD+XOYA1d+mRQ@mail.gmail.com>
References: 
 <CAAGawe0-K8f3RLoDLS2UsWDL4Ui1UwDN5rknLu0jWY40a5H9yQ@mail.gmail.com>
	<CAEWfVJnHfddKbJf9Ms9tkF91sPh_sZCYHSof3UsLzPgvak2pfA@mail.gmail.com>
	<CAAGawe0bQD8UQ1iYOLF+cNMS+ESR9JkyeEotdgD+XOYA1d+mRQ@mail.gmail.com>
Date: Mon, 5 Jan 2015 18:19:10 +0100
Message-ID: 
 <CAAGawe2o=62NdMCXynPJdX_zh5hqEsM=d_1tyyFTaW4g158Krg@mail.gmail.com>
Subject: Re: Should we implement the W3C DDR standard or not?
From: Werner Keil <werner.keil@gmail.com>
To: dev@devicemap.apache.org
Content-Type: multipart/alternative; boundary=089e011764eb7fd065050beae347

--089e011764eb7fd065050beae347
Content-Type: text/plain; charset=UTF-8

Some of that is also mentioned by the MIS fact sheet:
http://www.w3.org/2005/MWI/DDWG/drafts/api/MIS-DDRSimpleAPI/slide10.jpg
AFAIK he did that at least initially with a W3C DDR compliant library like
OpenDDR, Eberhard applied persisting device data into a cache store or
NoSQL DB already.
Changing the vocabulary or even parts of the implementation at runtime
without restarting the JVM would work through OSGi. At the moment it is not
applied, but a rather modular approach (compared to just a single large
parser class in the current classifier, even both XML files are processed
by a single class) makes that easier where necessary to adapt without
changing the Service layer or other core components.

Werner


On Mon, Jan 5, 2015 at 6:10 PM, Werner Keil <werner.keil@gmail.com> wrote:

> With a few exceptions where patches to device data are mainly asked for
> via JIRA there is no massive change on a daily or even hourly basis from
> what we know now.
> I mentioned given there is a solid, stable, mature and reliable W3C DDR
> client for Java since the early days of this project (changes mainly for
> the sake of package naming according to Apache standards, then where the
> device data had changed e.g. by introducing new categories of device, that
> was also accomplished and all clients are currently compatible)
>
> If in a year or more the structure may so drastically change, that some or
> all files became incompatible with the W3C standard, none of us can tell,
> because at most there is some vague "vision" for a 2.x data structure that
> (regarding the use of "3 files") does not differ from the number of
> data-bearing files in the current repository.
>
> More importantly, the W3C Spec offers tool to cover "Aspects" and a
> vocabulary: http://www.w3.org/TR/DDR-Simple-API/#sec-vocabularies but it
> does not mandate a particular format or how many files such vocabularies
> shall be stored in. Hence, if a 2.x format looked differently, as long as
> you get n properties out of it, a V 2 W3C client will also still work.
>
> You (Bertrand) should know the Java Content Repository (JCR) standard
> rather well;-)
> The JCR API just like W3C DDR defines a set of base elements like
> Property, Node, Value, etc. but it neither mandates what the names of each
> property have to be in a particular solution nor if you use a flat file
> system (like XML) RDBMS or NoSQL DB to persist those values. Same concept
> with the W3C standard.
>
> Werner
>
>
> On Mon, Jan 5, 2015 at 5:51 PM, Bertrand Delacretaz <
> bdelacretaz@apache.org> wrote:
>
>> On Mon, Jan 5, 2015 at 5:34 PM, Werner Keil <werner.keil@gmail.com>
>> wrote:
>> > ...It's not necessarily about 2 or 3 Java clients (some may be W3C
>> compliant,
>> > others not) but the question, if DeviceMap wants to offer at least one
>> W3C
>> > DDR standard implementation for languages and platforms where this is
>> > justified....
>>
>> As far as I'm concerned, if someone is willing to maintain a W3C DDR
>> client implementation that's fine.
>>
>> The question is whether this has impact on the device data set that's
>> going to be shared between the different client implementations. That
>> data set is the focus of DeviceMap, so it's important to make sure it
>> can be maintained easily without conflicting requirements. Do people
>> see potential problems with that?
>>
>> -Bertrand
>>
>
>

--089e011764eb7fd065050beae347--