Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[REBOL] Re: The XML Schema compiler

From: maarten:koopmans:surfnet:nl at: 14-Nov-2002 14:38

Bryan, Point taken and understood, Relax-NG lokks much better indeed. --Maarten bryan wrote:
>>The XML Schema compiler, XSDC. > >>xsdc compiles a XML schema definition to a Rebol parse definition that >>knows how to compile and validate documents for the specified xsd. > >>The output parser is thus much faster than a generic XML parser. >>xsdc speeds up the implementation of formats in XML/XSD unbelievable! >>You can implement XML based formats in hours where it would have taken >>days or weeks in traditional languages like Perl, Java, or C/C#/C++. > > I'm gonna take some exception to that in the response below. > >>The programmer itself can provide handler based functions, just like in > > a > >>SAX based XML parser, to handle specific tags with their content and >>attributes. > >>Now, that is our killer application. Where can I download it? > > NOOOOOO! Sorry to get so agitated but I must start in on this before it > goes much further. XSD sucks! Uh - Let me back up and start again. > > I've done quite a bit of work with Xml schema and other Xml validation > technologies, the company I work for specializes after all in helping > other companies set up their Xml based solutions. > > So why does XSD suck? > > 1. It is difficult to author, the specification is basically built for > E-Commerce applications that need to use Xml, since it was felt in that > community that Xml's typeless structure made it too difficult to work > with in their particular problem domain. > > 2. It will not support every possible Xml structure. No doubt caused by > it's intended use for E-commerce XSD is not flexible enough, or at least > no one to my knowledge has made it work, to describe formats as complex > as XSLT. > > 3. The datatypes supported via XSD, or the datatypes you can easily > build with it, are extremely limited. This does not cause much of a > problem when one is actually building an e-commerce solution(as long as > you are willing to pre-process your data into a structure the schema > will accept, something which really gets my goat!), but if you are > trying to use XSD to build other types of solutions you will quickly run > into problems. Two examples that always piss me off whenever I see XSD > used for anything that is supposed to be Human authored Xml are people > trying to validate Money and Dates. What are the problems there, well > since XSD does not have a currency datatype people generally do one of > the following: > a. Say that money has to be xsd:string > > b. say that money has to be a xsd:decimal, i.e if you have > $10,000.00 you have to write 10000.00 no chance of errors there huh? > c. Create a Regular Expression that allows you to write > 10,000.00. There are some complaints there of course, for example in > Danmark 10,000.00 is written 10.000,00 a regular expression that allows > you to do both. > > Dates suffer from the problem that XSD only supports Gregorian Dates. > I'm not gonna expand this email to booklength to complain about this. > > A propos Regular Expressions in XSD these are Unicode regular > expressions, could this be problematic in Rebol? > > 4. There are some complaints from very clever people, such as Tim Bray, > James Clark, not just that XSD sucks but that parts of the specification > are incomprehensible and that as a consequence one should worry that > Schemas written that take advantage of the more ersatz elements of the > spec will perhaps not be portable between different Schema processors. > > Given these problems what are the benefits of XML Schemas? > > Xml schemas are basically Object-Oriented in structure, the only > situation in which I see an actual benefit to XSD is in systems such as > .Net where one can do runtime translation between the XML Schema > datatypes and the supported environment datatypes, if we did this in > Rebol it might be useful. > Otherwise I do not consider that the ability to generate code from an > XML Schema is of any great value, there are code generators for various > BNF-based dialects, code generators for raw xml, code generators for > ANS.1, code generators for RELAX-NG, yadda yadda yadda - the world is > drowning in code generators. > > What do I suggest? > > I already indicated above that my aversions to any sort of support for > XML Schema might be lessened if I could do runtime evaluation of xml > instances and translation between schema datatypes to Rebol datatypes. > This however is not what I consider the sweet app. > > If there were to be any sort of code generator I would think one for > Relax-NG would be preferable - > > > Why? > > 1. It is easy to author, basically anyone with a good understanding of > their xml structure can learn Relax-NG in a day and write a schema for > it(it is often claimed an hour but I don't want to seem to liberal on > that score). > > 2. It will support every possible XML structure including complex > structures with variant content such as XSLT. May be of some use if we > want to build an XSLT processor in Rebol ;) > > 3. Although it is not often thought of as a datatype language you can > support datatypes in Relax-NG > > ttern > > 4. Easy to understand. Thus easier to implement. > > 5. There are tools, for example Sun's RelaxNGconverter that converts > various other validation languages into a Relax-NG instance. > > > Another sweet app would be Rebol implementation of Schematron > , especially > as that would involve support for Xpath. > However as there are Schematron implementations built using XSLT, maybe > we should have a Rebol implementation of XSLT? I wanted to get good > enough to build this myself, but hey I'm just as willing to let someone > with more Rebol beneath the belt build it and let me reap the benefits. > If we did have an XSLT implementation I could write rewrite the > skeleton1-5.xsl to output Rebol code no problem. >
-- Maarten Koopmans Innovation manager tel: +31 30 2 305 324 SURFnet bv fax: +31 30 2 305 329 P.O.Box 19035 email: [maarten--koopmans--surfnet--nl] NL-3501 DA Utrecht The netherlands