[
Lists Home |
Date Index |
Thread Index
]
3/5/2002 3:02:27 PM, Nicolas LEHUEN <nicolas.lehuen@ubicco.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
started. Sigh.
Thanks, very helpful.
|
