RE: Schema Modularisation in XForms (Was: xslt stylesheet for xformsto xhtml)

>> Hmmm, all this seems a bit arbitrary to me. What you are saying
>> is that there can only be one schema language, because of the
>> danger that someone might implement something that only used
>> their own, private schema language. However, if a small company
>> did this, they simply wouldn't sell their product very widely -
>> and this might actually be fine for a niche market. If a
>> Microsoft does the same, then everyone else will support it, in
>> the way most word processing packages support a multitude of Word
>> formats, past and present.

>Not what I'm saying at all. If you are passing around XML data, both client
>and server can validate that data against any schema language and still be
>interoperable. However, that doesn't apply to SOAP and XForms. Both client
>and server need to understand the schema language used, and that schema
>language is tied to the data.

Apologies if I misunderstood, I am pretty new to XForms. I still don't think I understand your point, though I would like to, if you have time to try one more time for me.

>> I hope that people use the schema languages that seem most
>> appropriate to their needs. After all XForms has invented its own
>> schema language to make up for lack of features in W3C XML Schema
>> and to provide support for well-formed XML.

>XForms did not invent their own schema language.
 Oh, well, sorry. I think of XForms constraints as providing validation functionality on top of what W3C XML Schema gives me, so I'm afraid I tend to think of them in terms of schemas.

>> We are thinking about
>> using Relax and/or Schematron for the same reason (they are/will
>> soon be standards, and are more general purpose than XForms
>> constraints). If XForms supports Relax, then fine; if it doesn't,
>> someone else will come up with a mechanism for transforming Relax
>> into W3C XML Schema and/or XForms constraints. If vendors think
>> that support for Relax, or Schematron will sell their products,
>> they will offer such mechanisms built in to their XForms
>> implementations. If not, a bit of preprocessing may be in order.

>If every client must support an arbitrary plugable language to determine the
>XForms model, kind of defeats the "XML Schema is too complicated" argument.

Maybe W3C XML Schema is complicated, that wasn't really my worry. I just find that it isn't expressive enough. I had assumed that the XForms working group had found the same, hence the extra validation constraints one can add to the XForms model. My thought was simply that I might be able to express such constraints using existing vocabularies, in much the same way that XForms constraints do not really duplicate what they get for free from W3C XML Schema. I appreciate that XForms must also support schemaless environments, and so it behoves it to have some schema like features.

>> I don't think it really matters one way or the other - as long as
>> we can map between languages, which is the whole point of using
>> XML for such things in the first place. It is probably sufficient
>> for you to argue that XForms is quite complicated enough already,
>> without adding plug-in schema language support!

>So you can get support for at least 3 schema languages on a mobile phone by
>writing some mapping code? I don't think so. That is why XForms only
>requires XML Schema datatype support as a minimum. And their ain't any
>datatypes in Relax and Schematron in any case.

Well, if, for the sake of argument, we assume an existing schema language which is able to express the same types of constraint as XForms, and that I already have some of these schemas; what is wrong with me trying to map them to XForms syntax? I just want to reuse stuff if I can. If you don't think this is likely to prove possible, then fair enough, I appreciate the warning. What do you see as the main stumbling blocks?

Incidentally, I think Relax has pluggable support for data types, so you can use the supplied W3C XML Schema datatypes, or not, as you see fit. 


Mark

Received on Tuesday, 3 September 2002 11:23:36 UTC