[lextypes] data type thoughts

[Bob Foster]

Opinions and questions below.

> These are just a few of my meanderings; maybe they'll be a useful place
> to start, maybe they won't.  You're all quite welcome to tear them apart
> or replace them with your own thoughts.
>
> Data typing seems to be a field with an enormous diversity of opinions.
> The same sets of issues crop up in databases, XML, and programming
> languages, and are solved differently by different groups even within
> those categories.
>
> There are a few axes of opinion I keep encountering (none are simple
> binaries in practice):
>
> Intrinsic vs. Applied - Some people seem to think that data types come
> from the information itself, while others see data types as metadata
> applied to information, something that can be changed or discarded at
> will.  Some people see the types as intrinsic but want the metadata made
> explicit during processing.

My general point of view is that XML (atomic) types should be named
descriptions of sets of strings.

Intrinsic types, from integer to furniture, but the strings "1" and "table"
are not intrinsically anything but strings. Nor do type names have any
intrinsic semantics; they are just names.

As for metadata, do you have some specific examples in mind?

> Validating vs. interpretative - Some people just want a yes/no answer.
> Is this good data, or not?  Other people want to be able to make
> statements about the data, and compose or decompose it according to
> rules about the information.

Is this actually a dichotomy or the beginning of a list of type-related
services people want. Some want a yes/no answer but many more want one
accompanied by a meaningful diagnostic. Some want to be able to interrogate
the types discovered during validation. Some want assistance with
translating XML types to and from programming language types. Etc. There is
a list.

Examples please for "statements about the data" and "compose or decompose it
according to rules about the information"?

> Serialization issues - I can't describe this cleanly, though I bounce
> into all the time.  Some people see XML merely as a container for
> information described elsewhere, and therefore don't see lexical
> representation as an issue, provided that it's standardized and
> understood by the elsewheres.

Type-related translation service? (Some people don't care about XML
representations, but they should be thankful that somebody does.)

> Ad hoc vs. structured - This axis has a lot of different dimensions, as
> there can be an ad hoc foundation on which structures are built (kind of
> like W3C XML Schema Part 2 with its many primitives plus rules for
> extension and restriction). Other people would like to start from
> strings - text being at the foundation of XML content - and build up
> from there.

Just to put a stake in the ground: Each application should be able to define
its own type systems with no more in common than the RELAX NG "text" type.

Structure in types (base types, subtypes) is good to the extent it is
rational and useful to an application. A good argument for type hierarchies
is they save time defining new types. Good arguments against type
hierarchies is no two people seem to be able to agree on one and committees
are capable of producing very bad ones. I believe the good can be had
without the bad by concentrating on tools that allow applications to define
type hierarchies.

> I've argued for a while that types are applied ('painted' is my favorite
> description), that they can and should be interpreted, and that valuing
> lexical representations is a good way to build flexibility (even human
> flexibility) into otherwise brittle systems.  I'd also like to see a set
> of rules for describing and processing types which is built solely on
> the textual (or conceivably markup, though that's risky) content of an
> element and defines a pathway to a value space or spaces.

Makes sense.

> I'm aware that this is considerably less concrete than the proposals I
> mentioned in the previous message, but I'd like to get a sense of what
> people are looking for before mixing and pouring materials which set
> permanently.

Yes, a lot of good ideas there, but it's good to back off a little and try
to get a sense of how people see the issues.

Bob Foster