Lists Home |
Date Index |
3/5/2002 3:02:27 PM, Nicolas LEHUEN <email@example.com> wrote:
>1) The fact that adding type information creates a data model much more
>complicated than the Infoset. People have to agree about types, about their
>names and their semantics.
True for both in-band and out-of-band. The in-band system is automatically
pluggable and extendible.
>Your example is OK provided everybody knows what is an "Int". I think XML
>Schema so-called "simple" types are a precious thing here. Why not use the
>xsi:type notation, while we're at it ?
Right. I guess I was just trying to be generic, i.e. "starting from
scratch." I should have used the xsi:types in the example.
>For complex types, this is way more complex. You need a structure
>definition, and you won't be able to embed it inline. You can still use
>xsi:type, but you'll need a schema document to refer to.
Good point ... the first REALLY convincing one I've seen, IMHO.
>2) Obviously, there is a verbosity and readability problem.
Uhh, namespaces killed that long ago :~) Anyway, "readable"
documents are mostly string typed, no?
> The situation
>in which some legacy code needs <firstname> first, then <lastname>, and a
>new document in which those elements are in reverse order cannot be handled
>by AFs, for example.
Another problem that XPath and related tools (XSLT, Schematron) solves ...
>Anyway, OOP provides interesting concept regarding "contracts", "extension
>of contracts" etc. Those are public interface of classes (or pure
>interfaces) and inheritance. A schema language like XML Schema also support
>those concepts, yet it is very difficult nowadays to access to schema
>information from a random XML document (or even from an XML document with an
>associated schema, because PSVI is not widely supported for now).
OK, I think I see the advantage of an "out of band" schema in this scenario.
But that brings us back to the PSVI "chicken and egg" problem that got me
Thanks, very helpful.