Not saying different schemas, saying different schema
language, as you indicated that we must have a common schema language
Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
"Paul
Trevithick" <paul@xxxxxxxxxxxxxxxxx>
|
"Paul
Trevithick" <paul@xxxxxxxxxxxxxxxxx>
Sent by:
higgins-dev-bounces@xxxxxxxxxxx
04/18/2006 09:58 PM
|
Please respond to
"Higgins (Trust Framework) Project developer discussions"
<higgins-dev@xxxxxxxxxxx>
|
|
|
To
|
"'Higgins
(Trust Framework) Project developer discussions'"
<higgins-dev@xxxxxxxxxxx>
|
|
cc
|
|
|
Subject
|
RE: [higgins-dev]
Revised Higgins data model goals
|
|
But if each Context Provider declares that it
uses a set of schemas and these schemas are expressed in different languages
then we aren’t we throwing the interoperability burden onto the app
developer (ie. above the Higgins API)?
I propose dictating that every Context Provider must express its
schema in a common language so that Higgins apps only need to understand one
language. (I’m emphasizing Higgins apps when in fact in our recursive
design another Context Provider might be the “app” consuming the
Higgins API). If one app wanted to unify/integrate data from N contexts
wouldn’t that app be burdened with supporting multiple language
converters? Never mind the lossy-ness of the conversions...
Tony wrote:
Paul what
you are saying is that I can't represent the same data in different schema
languages and this is where I disagree, as we do this in all the programming
languages today.
Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
"Paul Trevithick"
<paul@xxxxxxxxxxxxxxxxx>
|
"Paul
Trevithick" <paul@xxxxxxxxxxxxxxxxx>
Sent by: higgins-dev-bounces@xxxxxxxxxxx
04/18/2006 07:43 PM
|
Please respond to
"Higgins (Trust Framework) Project developer discussions"
<higgins-dev@xxxxxxxxxxx>
|
|
|
To
|
"'Higgins (Trust Framework) Project developer discussions'"
<higgins-dev@xxxxxxxxxxx>
|
|
cc
|
|
|
Subject
|
RE: [higgins-dev] Revised Higgins data model goals
|
|
I disagree. With only a common data model that meets goals ([1]-[10] except
[7]) and no common schema language only the most basic interop is possible.
Perhaps you are saying that we should set the interoperability bar at this
lower, read-only level? To move up the chain of interoperability to where you
can to edit the attributes and relationships of objects requires that the
editor understand what changes to both values and structure are allowed.
Without a common schema language I don’t see how this higher order
interop is possible.
Tony wrote:
Item (a)
is not mutually exclusive, as actually at some point both are needed, I see a
single data model and multiple description languages.
Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
"Jim Sermersheim"
<jimse@xxxxxxxxxx>
|
"Jim
Sermersheim" <jimse@xxxxxxxxxx>
Sent by: higgins-dev-bounces@xxxxxxxxxxx
04/18/2006 06:49 PM
|
Please respond to
"Higgins (Trust Framework) Project developer discussions"
<higgins-dev@xxxxxxxxxxx>
|
|
|
To
|
<Higgins-dev@xxxxxxxxxxx>
|
|
cc
|
|
|
Subject
|
Re: [higgins-dev] Revised Higgins data model goals
|
|
9 and 10 talk about schema, and seem to say this:
a) Some schema data model or description language is desired
b) Schema is tied to a Context, and is applied to everything in that
Context (I'm inferring this)
c) Objects (I assume we're talking about DigitalSubjects) have a
governing schema description
c.1) An object's schema description governs the data allowed/required
to exist on the object
Beyond that, this is not mentioned:
d) Schema descriptors may apply to data elements of an object
(attributes/relationships). In other words, schema descriptors can be
used to govern certain aspects of data. i.e. a SSN may only hold one
value, a surname may hold multiple values.
I'm inclined to envision how some of these goals turn into reality in
my head, and then argue against the picture I see.
I agree with (a) above.
I disagree with (b). It seems unreasonable to tie everything in a
Context to a fixed set of schema descriptors, especially where a Context
may be fabricated from the conglomeration of disparate data sources or
other Contexts.
I think (c) is fine as long as an object may be governed by an "any"
schema descriptor. When this happens, an application should be able to
enumerate and examine each element that makes up the object (rather than
using a-priori knowledge of what it expects to be there).
I assume that the schema governing an object's data elements
(attributes/relationships), is discoverable given that element's
identifier. In other words, an application can see an identifier like
xyz://foo/bar/surname and know how to access/display its data either by
some hard-coded knowledge of the "surname" schema descriptor, or by
looking up the "surname" schema descriptor and discovering things
like
form, sub-elements, allowed meta-data, multiplicity, yada yada.
I also assume that the schema governing an object's data elements
(attributes/relationships) is independent of the schema governing the
object which holds it. In other words, a xyz://foo/bar/country element
behaves the same whether its held on a person object or a device
object.
Is there a goal in terms of the access of schema? I mean, I see two
possibilities: 1) Schema is accessed via a Context or the objects held
with in the Context. 2) Schema is accessed externally (by following the
identifier's URL, and read using some external protocol like HTTP). I
think the goals are implying #1
Jim
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
