On 20-Jan-06, at 7:23 PM, Pete Rowley wrote:
John Merrells wrote:
I think most of this comment was based on your misunderstanding
above... so no silos....
My misunderstanding is based on the fact that the sxip attributes
are in the document
There are some example property names from the sxip.net authority,
but you can use anything you want.
I could publish the ones we've been using as another ID, or in an
appendix of a revision of this ID... but
I don't want to mandate that anyone should use them. It'd be nice if
they did of course.
yet apparently only sxip.net can supply the values (no matter where
they are stored).
Nope. What in dmd1 gives you that impression? It might be the
capabilities definition
stuff... only sxip.net can tell you the type information for that
property name.
In that case I don't understand
a) why they are documented since there does not appear to be point
of interoperability (these are for your website?),
They're not, but could be. I could publish them as a document on
sxip.org... then you could take a look at them and see if they make
sense for your application.
b) why a homesite would need to explicitly "support" the sxip#1
capability and advertise that support, since for the homesite they
are opaque attributes and it can either choose to allow the storage
of opaque random attributes or not, and any one user either has
those attributes or not - or is this a crude form of access control
for homesite storage?, where is the capable in capability?
Well a capability is both services and properties. I think you mean
why would a homesite want to advertise that it knew about a
particular family of properties.
But, yes. In a sense the Homesite is advertising what schema it knows
about. It could choose to operate in such a way that it only stores
properties that it knows about. Personally I think that'd suck. But,
given a set of Homesites a Membersite could chose the one most
appropriate for fetching or storing a particular property. Key to
Homesite popularity will be the UI/UX and that will be strongly tied
to what the properties are. As a user I'd want my DVD wish list at
the Homesite with the best UX/UI for that rather than for the one
with none at all.
and c) what exactly is the homesite expected to do to "tailor its
response" when presented with the dix:/membersite-accept when it
has no real knowledge of the attributes involved beyond what they
are called (and presumably the membersite requests only what it
does understand.)
Accept is mostly for the services part of the capabilities. For
example the authentication mechanisms used. Maybe the Membersite can
say that it can deal with particular security tokens...
Sorry to bang on about this, but I am actually trying to cut code
here :)
Which is why your questions are so excellent :)
That's exactly what I think we need and what I believe dmd1 enables.
What I mean by "meaning" is really the "universally understood
meaning" - not one meaning that only one entity understands .
Without universally understood meanings for a set of defined
attributes dix would merely be a means to use somebody elses hard
drive for data storage. There may be value in that for all
parties, but the greater value is when everyone talks the same
language, not just the same protocol.
Amen, and I refer you to our friends in the semantic web community....
However, people have over time come to agreement over what things are
called.
I think it's out of scope for this group what things are called, or
even how people
should come to agreement on that. It'll happen, but not here.
Don't get me wrong I want this to happen... and I'll publish the
names we're using
in sxip.net... and I hope lots of people will use them.
There are various social models for working out agreements for
the names of things.
None of which work terribly well once you switch on the computer,
but I'll agree not to mention it again until you buy me a pint.
Sure, after that we can sort out the whole world peace and hunger
thing too ;-)
John
_______________________________________________
dix mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dix
