I just read the updated RevisedDataModelGoalsM4.
- I think you may need to leave the "must" in 7b
if nested schemas are allowed. Otherwise it may be impossible to determine the
schema for a given object.
“must”
is now gone.
- the bit in [7] about a context provider returning a
schema data stream from a getSchema operation is maybe too specific for a set
of goals? For example, what I envision in the end (I imagine others have wildly
different views) is something like this:
- getSchema operation would either return an
enumeration of all schema elements, or alternately return a single schema
element specified by some identifier held on the data it's governing.
- Each schema element would be an object with an
identifier and a set of attributes (just like a DS in the most abstract sense).
- Schema elements governing DS's would have some
known set of attributes like: "allowed attribute types",
"required attribute types", etc.
- Schema elements governing attributes/relationships
would have attributes like: "cardinality", "data type",
etc.
- Schema elements governing data types is where I
potentially see some kind of "schema description language" employed
(more like a type description language). It's here that one needs to describe
that the type is something like: a sequence containing an {integer, an array of
strings, and an optional URI with a default value}. But even that could be done
by using more of the same types of objects (identifier and set of
attributes/relationships) couldn't it? For example: schema elements
governing data types could use other data type elements to build more complex
data types. A data type called usPostalAddress could itself
contain an attribute called "sequence" (sequence would be a
primitive type) which would name other data types like "streetAddress",
"city", "state", "zip".
I'm getting into too many details here. My point is
that the data model goals should allow us to eventually land on the appropriate
representation rather than specifying that the schema is returned as a stream
adhering to a language.
+1. The
word language has been removed. If we use a method-based approach as you
suggest, then there will be a lot of methods related to navigating and
inspecting the schema descriptions. OTOH this makes it easier for app
developers so probably a good thing.