RE: Device description structures and families

Just to re-iterate, we're not going to impose any particular implementation. The API, including the data types that pass through this API, are as far as we need to go. If we make API decisions that assume a particular implementation (e.g. an RDBMS) then we have a problem.

 

Even from our own commercial experience, we know that customers want our adaptation-supporting data mechanism to be available in a variety of forms, and for a variety of valid reasons. I fully expect that DDR implementers and hosts will want to do likewise. The user of the DDR will only see the API, and presumably will get the same results regardless of the underlying implementation. The difference from an implementation point of view could be with efficiency, costs, scaling or other "soft" (non-functional) characteristics.

 

---Rotan.

 

From: public-ddwg-request@w3.org [mailto:public-ddwg-request@w3.org] On Behalf Of Smith, Kevin, VF-Group
Sent: 26 March 2007 11:05
To: public-ddwg@w3.org
Subject: RE: Device description structures and families

 

Yes, the Vodafone example was just to illustrate that a family can be represented by a Boolean property, *assuming* a (usually human) certification process has been run to determine the value. So not the only way to do it, but I suspect others may wish to provide a pre-built family classification (the aforementioned gamescorp:bestSupport, for example).

 

If we don't allow open queries then at  least users wishing to perform complex queries could perform a periodic batch download of the DDR and use their own query layer.

 

Andrea, I see what you mean about views, but they are not arbritrary: the DBA would need to know the criteria (or at least the properties) in advance, which he would not for arbritrary queries...closest I can think of is a dynamic stored procedure, but again there would be so many permutations of query that it would be impossible to maintain. 

 

Having said that, I can see views providing efficiency for each of the Top N properties (assuming they are non-numeric or  unconstrained String)

 

NB Are views just specific to RDBMS? So far I've kept the DDR requirements at a high enough level to allow any kind of repository (LDAP, any XML DB), so if views are RDBMS only we could be forcing an implementation.

 

Also are we saying that an open query is anything with more than one selection critera (i.e., an AND in SQL).

 

Cheers

Kevin

 

	
________________________________


	From: public-ddwg-request@w3.org [mailto:public-ddwg-request@w3.org] On Behalf Of Andrea Trasatti
	Sent: 26 March 2007 10:43
	To: public-ddwg@w3.org
	Subject: Re: Device description structures and families

	It seems to me like the Vodafone approach is an approach that works at company-level only. I might care about VLive, but I might not. The DDR approach suggested here is much broader. 

	 

	I think that a first level of discrimination could happen at the user permissions level. As a DDR admin I could allow some users to run "open queries" or I might not, for example. Trusted users (or paying users) might have access to this, while some other groups of users might not.

	 

	Is this really where José wanted to go? Is this where the group wants to go?

	 

	Vodafone's approach is "I get a human down to check, if a device meets X,Y,Z requirements it's marked with a boolean value", that's OK, and works good for them. Allowing random queries can easily kill a DDR. But what if we build views? There could be the admin of the DDR defining the views and thus the families. The users will be allowed to request for the devices that make up the family.

	I thought this was what José wanted and not the ability to run random queries on the DDR. I might be wrong, of course.

	 

	Do we really want to have open queries in the default implementation? Sounds a lot like an extra feature that someone might want to add (maybe as part of a premium service) and some are not so interested in providing.

	 

	- Andrea

	 

	 

	Il giorno 26/mar/07, alle ore 11:06, Rotan Hanrahan ha scritto:

	
	
	

	[...]