Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[higgins-dev] More on schema goals

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.
 
- 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.

Back to the top