RE: [higgins-dev] Schema Languages (was Revised Higgins data modelgoals)

["Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx>]

Jim wrote:
> 
<snip>
> 
> If we have a single data model to represent Contexts and DS's, I assume
> we want a single model for the schema that governs instances of that
> data. I'm not sure why we're talking about schema languages, or even
> what that means,

I used the word 'language' because my presumption was that whereas the CPI
interface will support API methods to visit, read, write, etc. the objects
using the Higgins abstract data model, I wasn't assuming a similar kind of
interface to the schema language/representation/data. My thinking is colored
by the fact that in the current Higgins code a Context Provider has a single
getSchema() method that returns the entire thing in a stream. Hence my bias
in choosing the word 'language'. This is truly a nit. You can replace my use
of the word language with representation. I was also trying not to use the
word model again.

> but I do see a need to eventually describe the way in
> which an application:
> 
> a) discovers schema
> b) accesses schema (interrogate and update)
> c) uses schema to assist in accessing data (Contexts and DS's along
> with their data)

a) +1
c) +1
b) the "update" ability must be an optional function that most Context
Providers will not implement. This is because 99% of them will be
implemented in such a way that arbitrary schema updates "from the outside"
would cause their logic to break (as it was designed for a fixed schema (or
a fixed set of schemas if you prefer)).

> 
> Ideally, one unified model will be used for Contexts, DS's, and schema
> elements (where the schema for the schema elements is well-known). For
> example, a schema element needs to have attributes/relationships just
> like a DS does, just like a Context does. The difference is that when
> interrogating a schema element which governs a DS, one would expect to
> see certain attributes. The consuming applications would likely have
> built-in knowledge of what to expect on that type of schema element.  I
> _could_ see the need for meta schema elements which are in turn used to
> describe the schema elements themselves. That seems like more of a
> formality, but has proven useful in other (similar) areas.
> 
> In my mind, I keep drawing an analog to XML and XML schema. Both share
> the same (in this case) language (XML), and in XML schema there's only
> one way of representing things like choices, sequences, default values,
> multiplicity, etc. Otherwise, writing schema parsers would really be
> hard.

Agreed. 
> 
> The term "schema description language" and the notion of allowing
> different ones, makes me worry that we're trying to introduce something
> (or things) completely different from the Higgins model. 

Forget the "language" red herring. The notion of allowing different ones
makes me worry too.

I'm hoping that
> we're just talking about two completely different things. What sounds
> scary to me is having an application discover that ContextA's schema is
> presented as a file full of serialized UML, while ContextB's schema is
> presented as RDF schema.

Exactly.

> 
> Jim
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev