[DAS2] Re: question on properties

[Andrew Dalke]

Suzi:
> On the client side the appropriate behavior for these is different if 
> the data coming over from the server contains >1 prop element with 
> that tag.
>
> If the client sees "ssn" twice it winces and then either ignores or 
> overwrites with the 2nd value.

Or it says "error, error, cannot compute" and stops.  From one
of the guidelines ("the zen") of Python: "when in doubt, refuse
the temptation to guess."

> If the client sees "comment" twice then it appends the additional 
> comment.
>
> Question: Is this kind of information included in the spec? Uniqueness 
> vs. cumulative

Here's my thoughts.

We have several points for client/server extensions.
One is this property table, which is a set of key/value
strings.

Because they are strings you can use them for almost anything,
with the correct interpretation by the client and server.
That requires collusion between the two.

This is the extension point which is most familiar to everyone.
But it's open to the problem you pointed out.

The other is this non-DAS extension XML, which lets the
server add *anything*.  If the client doesn't know what the
field does it must ignore it.  If it does writeback with
that feature it must include the ignored element, and not
make any changes.

That means your server can add

<suzi:ssn xmlns:suzi="mailto:suzi at fruitfly.org">123-45-1534</suzi:ssn>

If the client doesn't know what to do, it ignores it.
It will never change the field.

If the client knows what that field does it must follow the
constraints set down for it, else the server should stop
with an error and not allow the update to occur.

There are two downsides to this approach.  There's no
way for a dumb client to understand that field, so no user
will ever see it, and there's no way to do a search on
that field.

(A server can extend the search syntax and tell the client
about the new syntax, but a dumb client doesn't know about
that.)

If there is need to support the dumb client then the
only way to support the data type constraints is in
the server.  It must check a given field and possibly
stop with an error or resolve ambiguities.  We can have
that the server reports an error message that the client
and/or user can use to figure out what's wrong.

Thinking about it a bit, it's possible to combine these
two.  For example, a server can have

   <PROP key="ssn" value="123-45-1534" />

then list as an extension

   <suzi:says-the-ssn-in-special/>

All this latter XML does is flag sufficiently aware clients
that the server implements the special SSN requirements.

A dumb client can ignore the flag, users add a new SSN,
and the server bails out, while the smart client early
on knows that that isn't going to be allowed.

This hybrid solution doesn't seem right to me though.

I currently (and without any experience) prefer putting
schema constrained fields in as extension elements.
Think of the property table as something exposed to the
user as a completely editable table, with no ability to
limit what that person does.

For the case of the SSN that might be overkill.  For
other things, like the current stage of a feature in
the curational process, it's best to put that data
there and not in the generic property table.

There is a long history of using generic key/value
tables as an ad-hoc way to extend a protocol.  I'm
trying to improve on that by defining a way for a
server to add well-structure, schema-dependent and
searchable data (for smart clients) without needing
to piggy back on a bunch of strings.


					Andrew
					dalke at dalkescientific.com