I'm not sure whether you'd class this as validation or as type
information but an important day-to-day requirement is the
cardinality information - an instance might have one occurance
of an element but the fact it could have more than one could
be quite important to a consumer of the instance. Not everyone
writes a schema, or a separate schema might not be available
at the time an instance is processed so it would be handy to
have this cardinality information in the instance.
This seems to me to apply all the more to type information
about the content of the element - it would be handy to have
it in the instance.
However, I think it would be more a matter of both-and rather
than either-or - it would be handy to be able to include the type
and cardinality info in the instance but also to be able to
separate it. So that's four requirements I'm counting
- type info within instance
- type info outside of instance
- cardinality info in instance
- cardinality info outside of instance
and it seems a poor show if all four can't be catered for (and
others besides).
Of course being able to use this info for validation is one use.
It's a handy one and allows something akin to test driven
design or development. It's not the only use for the info of
course. It's information vital to all kinds of use and processing
of the instance and for creating further instances of the same
'type'. In that sense it 'defines' the instance (along with other
info which could feasibly include semantics too if we were to
go a bit further in providing for typical requirements).
----
Stephen D Green
On 17 January 2013 08:39, Michael Kay <mike@saxonica.com> wrote:
> >the benefits of separating a contract from what it governs are
> substantial, in my experience. ht
>
> Agreed, but that's validation.
>
> If you follow the argument about separating type information from instance
> information to its logical conclusion, you end up sending
>
> 117-273419823y186tr837y8yw
>
> in one message, and a document saying what columns 6-12 mean in another.
> We've moved beyond that.
>
> Michael Kay
> Saxonica
>
>
>