[
Lists Home |
Date Index |
Thread Index
]
>> So I'd suggest that XSDL's attempt to produce a universal
>> system isn't a success, and that the first thing to begin
>> with is to define the minimal role of typing in XML. Perhaps
>> it's possible to move conversion from the application into
>> XML (although I still don't quite understand how one is going
>> to map, for instance, signedInt into perl or python without
>> writing a specialized constraint handler of some sort, which
>> effectively puts it back into the application), but I don't
>> think that this should be the focus of simple type
>> definitions. If it's supposed to be, then the type
>> definition probably ought to include the target language or
>> languages. And in any event, validation of primitive types
>> is the first step to actually doing the conversions, and
>> specifies the *XML content*, rather than per-language conversion
APIs.
>Your experiences do not mirror those of most people I know. XSD has
been
>a boon to creating mechanisms for transparently serializing objects
into
>XML and back. .NET users utilize it all the time and the only
complaints
>I have seen are that the functionality we provide is not fully featured
>enough.
By fully featured enough I'm betting there's complaints about
datatyping, and extension of types?
I'll admit the ability to convert between xsd datatypes and .net
datatypes using System.Xml.XmlConvert is one of the only benefits I can
think of for xsd.
Let us for a moment consider what are the three most oft-stated benefits
of xml schema:
1. It's Xml; well so what, plenty of things are xml, doesn't
mean they're all usable. RELAX-NG can be Xml as well, and Schematron is
Xml, and XER and XDR for that matter; so that a schema language is Xml
should no longer be used as plus, it should only be a minus if it were
not.
2. It's got datatyping; I submit that is only beneficial to
strongly-typed languages(or strongly typed Frameworks?), which most
languages used in development nowadays are|aren't? what's your opinion.
I believe the statistics I read indicates that they aren't, and I
personally have a preference for weak typing. At any rate as was pointed
out by Mr. Clark in his original message the datatypes in XSDL are not
exactly all that useful, really ask yourself - how many Xml dialects
have you seen for e-commerce etc. where the element Price is of datatype
xsd:string, let me say I've seen a few, from reasonably large companies
also. HAH how useful is it if you can generate code directly from your
xml schema that allows 'My Aunt Fanny' through(here I jump slightly
aside to the subject of code generators from XSDL the usefulness of
which I am uncertain of). The best ones seem to be happy saying price
can be a decimal, do users maybe mess up often by entering $1,000.00
instead of 1000.00 - of course most often they allow you to write
something like: <currencyType>USD</currencyType><price>1000.00</price>
still not what I consider optimal; and how many users are going to be
happy entering in Gregorian Dates? Well you get the point.
3. Including and extending Schemas. Okay this I consider useful,
despite problems pointed out on this list. The question I have is how
often people actually will do it right. That however is only a partially
reasonable complaint against useful functionality, that developers do
not use it well or often. Including me, sometimes it's just easier to
write a schema without including anything, or writing the whole schema
and then separating out sections into includes. But yeah, once
everything is separated out I can handle it better and quicker.
Okay now please no one tell me the ways to handle the problems posed in
number 2, such as Schematron in xsd:appinfo, I'm aware of that, but this
raises it's own problems. Or the necessity of doing chained validations,
which seems to me to have become inordinately popular for a technique I
would think should only be necessary in instances of very tightly
constrained and important data. I submit that these techniques indicate
the non-usability of xml schema for what it was supposedly designed,
validation of xml instances. That is what it was designed for, right?
Finally the fact that .Net users use it all the time; does this apply to
Schemas that they generate for instance documents - forgive me here I
seem to remember seeing a schema generator for VS.Net sometime, as I
just use the Framework I'm unfamiliar with the functionalities of VS.Net
- does it apply to Schemas that others have written, or does it apply to
Schemas that they themselves author? I submit that if it applies to the
second then the "accounting" for development time could be screwed up
without accurate measurement of time taken to write the schema, which I
bet could have been more quickly written in another language. This would
seem to be another situation of the "Real cost of Xml Tags" as Sean
Mcgrath would put it, I bet he never thought the principle would be
applied to XSDL itself, when he seemed more concerned with the languages
defined via XSDL.
Anyhow I could go on and on. But I think I'm about ready to pop a blood
vessel. :) Sorry if this post was somewhat unstructured.
|
