Lists Home |
Date Index |
>I assume you are saying that XSD can do -without- types, and to the
extent that XSD is used as a language
>to express -syntactic constraints- on unicode strings, this is certainly
true. The point of semantics is that
>now that we have a piece of XML that let's say corresponds to some RNG
pattern or XSD type _now what_.
>How can we specify how different programs i.e. processes might use this
piece of XML in an
The key word there is "processes". For specific processes to interoperate
we may want higher order
labelling (i.e. types) than UnicodeWithAngleBrackets provides.
But - and I think this is the key point - those labels will be specific to
the interoperability needs
of specific processes at a point in time. They do not need to be innate in
the XML itself. Indeed,
putting them there reduces the usefulness of the XML.
For example, what happens when we want to change the processes? If we
tightly couple process-specific labelling
into the XML, we need to revisit the XML. If however, we loosely couple
process-specific typing as a downstream
process from the UnicodeWithAngleBrackets, we can tweak the
process-specific "object models" or
"data types" or whatever they are called without revisiting the XML. We
only need to revisit the XML if
we need something not already represented in the XML.
In my experience, this is a really useful level of loose coupling which has
saved me countless programming
Its weird, XML is mentioned as a key technology in the whole loose
coupling, web services, service oriented
architectures thing and yet boxed XML tightly couples things (like
typing) in a counterproductive way.