Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


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

From: Rick Jelliffe <rjelliffe@-------.---.-->
To: xml-dev@-----.---.---
Date: 9/20/2008 2:48:00 PM
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


transparent
Print
Mail
Like It
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent