Re: [xml-dev] Discover data patterns or Create data patterns?

[Rick Jelliffe <rjelliffe@allette.com.au>]

Michael Kay wrote:
> Rather than "uncover patterns", I would say "formulate abstractions". But it
> amounts to the same thing.
>  
> Either way, data analysis is essentially an exercise in grouping objects
> into types, and the people who do it best are those who are best at finding
> useful abstractions. 
I am not sure I agree with the second para (and not sure my disagreement 
isn't quibbling and off-topic)

"Type" as people use the term in software languages, has an idea of 
mutual exclusivity between primitive
types: so that a string is not an integer for example. (No flames, I 
understand that LISP has print forms
for everything and that dynamic languages may have automatic type 
coercion and so on. But even in
LISP the debates about whether to have mixin inheritance is, I think, an 
example of the same problem
with typing.)

But there are many relationships which don't display this. These are the 
messy parts of XML Schemas,
for example: the KEY/KEYREF/ID mechanisms which are outside the type 
derivation system; and
the strangeness of derivation by union, not to mention the impossibility 
(=fragility) of moving from untyped to
typed by derivation (whaddayamean this text is not a String?)  or 
between primitive types (whaddayamean
this Date is not a String?)

So "pattern" is a much better word than type, I think, because it is 
more general:
an element may "have" a type (or be an instance of that type, or 
participate in that typedness) but
the element "is part of" a pattern. That was why I chose that word for 
Schematron, specifically to
say that we weren't doing typing (though in the mooted <property> 
elements for the updated ISO
Schematron there would indeed be slots for type information on parts of 
a pattern.)  XSD allows
you to ask "have" questions but only limited "is part of' questions.

The thing is that people will ask the questions their tools and 
standards support, and they will ask questions
their tools and standards have trained them to ask. And when the tools 
and standards don't allow those
questions, people just avoid asking them. For example, languages like 
SVG, XSLT and RDF really
are not well served by "type" notions, at least as the term means in 
concrete technology (i.e. XSD.)
(Which is not to say that type abstractions are not being improved.)

Cheers
Rick Jelliffe