| RE: [higgins-dev] Revised Higgins data model goals |
| "Paul Trevithick"
<paul@xxxxxxxxxxxxxxxxx>
Sent by: higgins-dev-bounces@xxxxxxxxxxx 04/18/2006 10:58 PM
|
|
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
|
|
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
|
|
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
