xml-dev - Re: Schemata are not just constraints

[allette <ricko@allette.com.au>]

 From: Bullard, Claude L (Len) <clbullar@ingr.com>

> The site cited (ooooh) notes that ontology meant a
> logic of existence.  If we go that deep, we lose
> ourselves in the ratholes of meaning
...
   As Martin mentioned, we can
> look at the utility of substitution groups.

I tend to think that much of the difficulty we have with schemas
is precisely that of people not being aware of the ontological
possibilities: that creating a schema language involves not just
picking a set of use cases but creating a coherent ontological framework.

What the hell does that mean (I hear Tim's voice) ?   It means that when we
create a schema language we adopt certain abstractions: Is there
inheritance? Are there abstract and final things?   Is a name simple,
two-parts, three-parts or a full path?  Are there types, do these form a
type hierarchy, is it a tree or a graph, are the children restrictions or
extensions, etc.

In Schematron 1.5, the main abstractions are patterns, abstract rules and
phases.
I tend to think of a schema language as something that growing naturally or
painfully out of four ingredients: the domain they are addressing (and the
boundaries of the domain), the schema paradigm (e.g. regular expressions,
path expressions, notation processing), the abstractions,  and the XML
language theories and tastes (including house rules) of the creators. For
example, DTDs provide almost no abstractions: instead they provide PEs which
shows the language taste of the creators (a minimalism that prefers to
re-use  a low-level mechanism used elsewhere rather than introduce new,
higher-level abstractions.)

While markup language theories and tastes can be fruitfully debated and
discussed (e.g. my book), I am not all convinced that there is much point in
having strong views on questions of ontological categories (in schema
languages for markup languages) except for questions of completeness and
inellectual congeniality. The same is pretty true of the schema paradigm.

...Because I think the proof of the pudding is in the eating (and will be
based on the demographics and times of the eaters). We simply need more
experimental schema languages--slicing the world into novel domains,
exploring different schema paradigms (and in what may seem to be different
domains), adopting different abstractions (ontological  frameworks) and by
people with different language inclinations or tastes (e.g., the difference
between Schematron and XLinkit, which have very similar paradigms but very
diffferent approaches to languages.)

I think that the most interesting possibilities are for schema languages
that
meddle with our ideas of what domains are natural that have the best chances
of being fresh: we tend to have very fixed ideas of what schema paradigms
are useful (e.g., document people accept the grammar pardigm, database like
the key constraint paradigm), similarly we tend to have fixed ideas about
abstractions (OO people love objects, LISP people love eval), and people
usually have strong convictions on good language design (e.g. PIs boo! --
elements hurrah!).

What might be examples of a cross-domain schema?   One might be a schema
language which ties entity structure to markup declarations and naming
conventions (i.e., a generalization of the XHTML Modularization system).
Another might be to tie the language of a document to the characters used.
Another might be to constrain the HTTP preferences (e.g. compression) for
accessing a resource by some aspect of a topic map which points to it.
Another might be to constrain parse trees according to a property set  (e.g.
like SGML GROVE plans).   Another might be to constrain extended-XLink roles
according to some grammar (e.g an architecture on the values of the role
attributes)

This may sound airy fairy, but it is practical. Why should XML Schemas have
key constraints and uniqueness, but not multiple inheritance?  Until we have
a broad range of different experimental and commercial languages for
constraining certain things in relation to other things,  we cannot know
what is powerful and convenient.

Cheers
Rick Jelliffe