Lists Home |
Date Index |
Simon St.Laurent wrote:
> It's very useful because the representation doesn't _require_ you to
> process it in a particular way. The looseness of the
> representation (as
> Uche pointed out earlier) is actually a benefit for
> exchanging XML among
> diverse processing environments.
I think several issues are being conflated in this and related threads:
1) Is strong datatyping a good and useful thing in modern programming
2) Is binding W3C specs to XSD a good thing?
3) Should we explicitly associate datatype information with elements (and
attributes) of an XML document?
2) is easy: no... and 1) is depressing academic (and everyone knows that
*real* programmers use strongly typed languages :-). W.r.t. 3), I still
disagree strongly. It isn't clear to me if you are processing (okay,
representing) book-type documents or data-type documents.
If the latter is the case, I guess the crux of your objection is that XSD
datatypes cover such narrow categories (read: there's so bloody many of
them) that they don't facilitate interoperability with other environments.
At the same time, the semantics implied by having datatype information is
really, really useful. Try this on for size: we define a set of primitive
datatypes that correspond loosely to what is available in most programming
languages: string, integer, date, float, boolean, enumeration. All other
constraints are expressed using Schematron. If you don't want to provide a
schema, the datatype information just isn't there and can't be used, but
everything else (i.e. XPath, XSLT, etc.) still works, perhaps with reduced
possibilities for optimization and design-time error checking.
Would that be okay in your view?
> Probably the easiest place to focus the criticism is the notion of a
> Post-Schema Validation Infoset. If you just use XSD for validation,
> you're only injuring yourself, and I won't complain to loudly. If you
> start defining XML specifications that operate on the PSVI, you're
> injuring a lot more than yourself.
Do you deny that the extra information in the PSVI is good and useful, as
long as it isn't required?
> Sure. I tend to recommend RELAX NG and Schematron as useful tools for
> making sure that markup meets expectations.
Sigh. What about, for example, generating a UI for entering XML data (a
really common use case)? Can you see how to do this without a schema? If
not, surely you agree that schemas are good for more than just "making sure
that markup meets expectations"?
> Perhaps. At this point, I'm pretty thoroughly convinced that
> any effort
> to apply strong typing to markup is in fact "a whole new class of XML
> processing apps" - and one that shouldn't be confused with XML.
I'm not sure what to make of this. I think this last sentence sums up what
I'm so passionately in disagreement with, but I'm not sure. Can you statein
a couple of sentences what you usually do with XML documents and how you
achieve this? Once again, if you're marking up books, then we're just in
different universes, but I strongly suspect that this is not the case. What
you're doing probably isn't the same as what I'm doing, but I refuse to
entertain the notion that what I am doing is not XML just because I actively
leverage schema information.