RE: Device description structures and families

Hello everyone,

The mechanism for assuring uniqueness of HTTP URI's is a combination of
their structure and of the reliance of the Web on the internet's Domain
Name Service. URI owners have to have rights to the part of the domain in
which they can create URIs. They also have a responisbility not to create
URI collisions. [1] discusses this. Of course, implementations that help
people to achieve those recommendations are a different matter.

In this particular case, URIs related to W3C specifications are normally
within the W3C's domain and are allocated by the organisation. That would
presumably work for families that were standardised. For extensions, then
presumably the company or organisation making the extension would use a
URI in a domain that they owned.

Maybe I'm missing something here?

By the way, pointing this out doesn't necessarily mean that I'm
necessarily in favour of representing families explicitly in the DDR. I
haven't really formed a view. I just thought it worth responding to
Andrea's point about URIs and collisions.

Best wishes
Rhys

[1] http://www.w3.org/TR/webarch/

  _____

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


This feels a lot like RDF's idea that if something points to a URI it must
be unique.
Something that actually strikes me about RDF is that the URI is not
required to actually exist, so how could you guarantee that nobody else is
using the same non-existing URI?

Also, wouldn't it generate a run for the best names as it happens with
domain names? Would you suggest to lock premium names as someone recently
did?

- Andrea



Il giorno 26/mar/07, alle ore 14:27, Rotan Hanrahan ha scritto:


Here’s an idea…



The uniqueness of family definitions can be guaranteed if we use URIs to
indicate families. If we dereference a URI we should obtain an expression
that is applied to values in the known vocabulary (-ies). Short names like
IsPDA can be defined centrally for convenience, but this would only be a
shorthand for the corresponding URIs, and only for a few key definitions.



A DDR could, if it wished, restrict the use of Family URIs to a defined
set of sites, thus taking some control of arbitrary query expressions.



We might  also insist that the information obtained at a Family URI was
fixed, so that the expressions could be cached, or alternatively use the
existing HTTP caching mechanism with extended periods of validity (because
the Family definitions should change very seldom, if ever).



This is just an idea. I am not saying that this is the way to implement
the DDR, as we should avoid getting into the implementation details. It is
just useful to consider the implementation possibilities so that we are
confident that our API/vocabulary ideas are viable.



---Rotan.



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



Kevin, the use of the term "view" was to give an idea of what I meant.



An idea (and I'm not saying this is necessarily the way to go, but just
sharing some thoughts) would be to have an admin interface where an
administrator can define a family say "PDA are all those devices with at
least 320px wide screen, stylus OR full keyboard,  PC sync". It's the
definition of the admin of MY DDR. The API should also provide a way for
this DDR to communicate to other DDR's or clients what the family
definition is.

Other DDR's may create a family called "PDA" as much as mine, but with
different filters. If the group thinks the family names should be unique,
then we need a central authority to assign names, but this is far out of
scope, IMHO.



How the DDR will implement the definition and "maintenance" of the family
is up to the DDR developer. It can be a view, it can be a stored
procedure, it can be a csv file generated once a day. It will be up to the
DDR owner to let its customers know if the list of devices that are part
of a family are outdated or MIGHT be outdated or are generated in
real-time.



- Andrea



Il giorno 26/mar/07, alle ore 12:25, Rotan Hanrahan ha scritto:





As I see it, José was talking about a particular type of structure: a
family of devices. Such a family is defined by a membership expression.
The question is: who provides those expressions? It is possible that these
are provided centrally, so that there is, for example, a central
definition for the IsSmartPhone family and the IsPDA family etc. In this
case, the expressions can be pre-evaluated and the results stored. No
performance issues to worry about.



But perhaps, as a user, my idea of a PDA is not the same as the official
definition, so perhaps I want to use a different expression. This would be
a run-time expression. Do we want to support such a use case? If so, it
opens all kinds of performance and security issues.



Of course, you could always mirror a DDR internally, and then run your
dynamic queries against your own mirror. That way, any performance impact
will be absorbed by the user of the DDR, not the provider.



This approach might have implications further down the line. Suppose the
DDR expands, as it will be designed, to include streaming capability
information. In such a case, a local mirror of the DDR for a video
streaming service will only be interested in data pertaining to streaming.
How would this mirror indicate to the DDR master that it only wants a
particular subset of data to be mirrored? This is another use of the
“family” idea, but not just applied to devices – it is applied to
subsets/categories of data within families of devices.



In terms of what the DDWG *needs* to do, if we have a way to identify a
single device (using an appropriate interpretation of “device”) then I
should be able to query the DDR for one/some/all of the data relating to
that device that is held in the DDR. How the DDR resolves that query to
produce the result is an implementation issue. In theory you could
implement it with a linear search through a flat file. The DDWG is not
responsible for determining how the processes are implemented, though it
makes sense for us to keep an eye on possible implementation issues, hence
my concern for performance and security.



---Rotan.



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:






The well-formedness requirement is insufficient to determine the
performance behaviour of an expression. I am particularly concerned with
the possible use of regular expressions, because a well-formed regex can
be massively inefficient simply because it is designed badly. A bad design
is not detectable (for a deeper understanding refer to work on
Deterministic Finite State Automata, NP-completeness of back reference
matching etc.). In effect, you cannot automatically predict the likely
behaviour of an uncontrolled query.



Of course, one can work around some of these deficiencies using quota. For
example, you may permit a query to execute for no more than 5 seconds, at
which point it is abandoned. Repeated quota-reaching requests from the
same source are eventually rejected immediately, thus avoiding DoS attacks
and other resource-wasting issues.



But I know (from painful experience) that some regex implementations
cannot be aborted (cleanly, or at all), so I can see implementers having
some problems.



Even without regex, queries can cause massive problems. Ask any SQL DB
designer about query tuning…



As for the use of Booleans, I assume that one of the following was used to
determine the values of the Booleans:

- A human examined the data space and determined from the existing values
what the Boolean value should be.

- A pre-determined expression over the available variables was evaluated
to get the Boolean, which is then cached.



So, the only difference is that in the Vodafone case the process is done
in advance, whereas in recent dialogue we have been talking about the
process taking place in real-time (at the time of query).



We’ve had multi-conditional support in our adaptive technology for many
years, and it can be supported in the recent DISelect (from the DI group),
so it’s not an unusual run-time requirement. In our own
experience/products, the query and the source of information are under
common control, whereas in the case of the DDR the source of the query and
the place of control are separate.



I think we need to look very carefully at this.



---Rotan.



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



I can only answer from my own Vodafone experience, where we do use device
families - however membership of these is usually represented by a single,
static Boolean property (isAdvancedDevice=true, isVodafoneLive=true,
etc.).

We sometimes make much use of multi-conditional queries, but these will
typically involve a dynamic property (e.g. hasMarkup=XHTML-MP and
hasBearer=3G).



So my opinion is:

- the interface must allow arbritrary, multi-conditional queries (with
efforts to prevent Denial of Service or slow performance, such as having a
validation step when receiving a query at the interface and rejecting
anything badly-formed)

- that pre-built classifications should be allowed in the repository to
indicate membership of a namespace-bound family.



Cheers,

Kevin









  _____

From: public-ddwg-request@w3.org [mailto:public-ddwg-request@w3.org] On
Behalf Of Rafael Casero
Sent: 24 March 2007 18:21
To: public-ddwg@w3.org
Subject: Re: Device description structures and families

In fact that is the reason why there is a different specification for a
server accepting queries related to static features and a server accepting
queries that requires processing.

I do not know exactly how the real implementations of a processing server
are but I know that they have mechanisms for rejecting demanding users or
queries.

If there are developers wanting to use the functionality, maybe there are
providers willing to offer it. Maybe what we have to do is study if there
are real needs for user defined families (or grouping)

Raf.Casero

-------- Mensaje Original --------

I have a practical concern regarding the use or arbitrary query
expressions (e.g. expressions that define family membership). It is
certainly possible to construct expressions that have a very heavy
processing load, as any SQL DB administrator will confirm. An expression
involving, say, poorly constructed regular expressions, could tie up a
processor for a considerable time. This places a serious and unpredictable
burden on the provider of a DDR that supports arbitrary query expressions.

The risk is both from deliberate denial-of-service attacks, and accidental
use of ill-conceived expressions.

I would be interested to know how the integrity and availability of a DDR
could be maintained in these circumstances.

---Rotan.

-----Original Message-----
From: public-ddwg-request@w3.org [mailto:public-ddwg-request@w3.org] On
Behalf Of Rafael Casero
Sent: 23 March 2007 14:06
To: Andrea Trasatti
Cc: public-ddwg@w3.org
Subject: Re: Device description structures and families


Yes, the ability to describe a stored family is an interesting
functionality. In the proposed solution there are families with a stored
definition (i.e. a company perform a study by which obtain a good
segmentation of devices and provides the resulting families as a
services) and temporary or dynamic families defined by a 'formula' or
'pseudo-code' by the requesting user, obviously, the query for the
family definition applies only to the first case. Technically, the
problem can be solved in the same way as the temporary or dynamic
families definition but in the opposite direction: the user can query
for the property definition and the DDR answers with the formula or
pseudo-code.

But, maybe there are some other cases in which the provider does not
want to provide that information, maybe the provider considers that this
information (the family definition) is his core business and do not want
to disclose it. We have to think on that scenario too.

In any case, we can add something like 'describeProperty' method at the
API level that can return the formula or the definition of a derived
property.

Related to the second point: if the family is a
previously-stored-definition one (i.e. provided by the DDR) there will
be no need for re-state the family definition. If the family is user
defined, the desired behavior  is to not need to re-state, but in that
case, DDRs have to maintain a session with the user allowing for an
initial definition an future many uses. We have to decide if the DDRs
must allow for a session type of communication or if DDRs must follow
the request/response schema.

If we are dealing with user defined (temporary) families the only two
ways that I can imaging is session maintenance or re-state the definition.

Well, those are just first thoughts about the problem, I hope it will
help to think on it and going further.



Raf.Casero


-------- Mensaje Original --------


This is very near to what I thought about families.

There are two cases that José described that I don't understand if are
matched in your proposed solution.

First of all is the ability for a DDR to communicate with the querying
individual the structure and definition of a family. This would imply
that the DDR is also able to store locally at least the definition of
the family. Processing can happen at the request time or stored.

The ability to determine if a device is part of a family. Would this
require the querying individual to also re-state the family definition?

- Andrea



Il giorno 22/mar/07, alle ore 11:17, Rafael Casero ha scritto:



Hi all,

I think there was a somewhat similar problem at OGC (Open Geospatial
Consortium) and maybe its solution can be useful for us too. In order
to explain the similarities (and then the approach) let me first
summarize a little bit our problem.

a) There are some 'static' device properties, for instance, screen width

b) There are, also, some other properties 'derived' from the 'static'
ones: we can say that belonging to a particular family is the result
of applying a 'formula', for instance,
(XHTML-MP = yes) AND (width > 128)  AND  (height > 160).

In such a view, the 'family' semantics is the result of applying a
formula (or pseudocode) . The way in which that is implemented in a
real DDR need not to be specified: it can be evaluated on demand or
can be previously evaluated and stored (like any 'static' property),
that will depend on the particular implementation.

The similar problem that OGC found is that they have 'features' that
are 'static' properties related to a particular location (i.e., there
is a petrol station at location x, y). For that they defined the 'Web
Feature Server' (WFS) that it is a minimum set of specifications that
a server must comply. Also they have a specification for a 'Web
Processing Server' (WPS) that allows for 'derived' properties or
calculated results (i.e., give me the petrol stations inside the area
defined by xMin, yMin, xMax, yMax). They separate both specifications
because the processing required in the second case can be much
demanding than in the WFS case.

Translating this specification to our case will be something like this:

a) Families can be defined as a formula or a pseudo-code

b) DDRs could have processing capabilities or not

c) DDRs, with processing capabilities, could store formulas (or code)
as a way to define families. The way in which they are solved and
processed (on demand, previously stored, etc.) depends on the
particular implementation allowing for a quality of service
differentiation between providers

d) Different families can be defined for different companies using,
for instance, name spaces. Then there can be also a business case for
the families definition (effective terminal segmentation)

e) Privileged users could be able to define 'derived properties'
(i.e. families) by defining the name (within a name space) and the
formula (or pseudo code)

f) Developers could define the 'formula' to apply in the query or
(depending on their privileges) store it as a 'derived property'

g) Effective terminal segmentation (families) can be offered by some
providers by defining particular formulas.

h) Developers can query for a 'static' or 'derived' property in the
same way transparently, only, maybe, they have to query to a
different DDR depending on the property queried. (Also there is here
a business case: the DDRs that can deliver 'derived' properties can
offer to their customers processing capabilities and good semantics)

This figure is like to mimic the OGC way of doing. Of course we have
to discuss if that model is of any use for us but I think is worth to
think at it.

What do you think about it?


- Raf.Casero

-------- Mensaje Original --------


Hi all,

I have started with some use cases regarding device description
structures [1]. Two of them are envisaged but not yet written :).

You are welcome to contribute with more use cases, like those that
Kevin and Andrea has mentioned these days in the list.

Feedback from the public and group members is also needed

Thanks and best regards

[1]
http://www.w3.org/2005/MWI/DDWG/wiki/DeviceDescriptionStructuresUseCases

Rotan Hanrahan escribió:


This would assume a common syntax for representing the family rules.



And this is precisely where I think the work that José is leading will
help us.

---Rotan

-----Original Message-----
From: Smith, Kevin, VF-Group [mailto:Kevin.Smith@vodafone.com]
Sent: 20 March 2007 15:48
To: Rotan Hanrahan; public-ddwg@w3.org
Subject: RE: Device description structures and families

Hi Rotan,

Thanks for the clarification...

Another use case is content filtering, e.g. indicating that 'this family
gets a movie, while this family gets an image'. Resolution of the
expression would involve confirming the requesting device is of a given
family. Then the appropriate link or object would be presented.

As both yourself and José say, there could be benefit in sharing some of
these family classifications: for example, a games publisher could create
a set of rules as to which devices can support their latest games for the
best user experience (mature J2ME, good CPU, decent resolution etc.) and
this could be represented as a family (possibly namespace bound, eg
gamescorp.bestSupport). They could also provide minimum criteria for
legacy games (gamescorp.justSupport). Maybe the provisioning of these
family rules can be in a DDR extension, or it could be possible in the
query to the DDR to ask for the family rules to be fetched from an
external source (such as gamescorp themselves). This would assume a common
syntax for representing the family rules.

Cheers
Kevin






[...]