XML validation against XSD schema

# Christian Mayer (13 years ago)

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

Developing a ECMAScript based rich application I came across the problem to validate a XML based config file against a XSD to be able to leave out error handling during the config file processing in my code.

But it seems there's no standardized way to it...

Did I miss something or is such a fundamental building block really missing? (Could it be added to the standard?)

With kind , Chris

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux)

iEYEAREIAAYFAk/Q33UACgkQoWM1JLkHou24rwCfZt2sBwrCefbEhm5pmRz7ZEVx zcoAn126ZKO+ceHnRkrhExfBITyJJrEO =larE -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Developing a ECMAScript based rich application I came across the
problem to validate a XML based config file against a XSD to be able
to leave out error handling during the config file processing in my code.

But it seems there's no standardized way to it...

Did I miss something or is such a fundamental building block really
missing? (Could it be added to the standard?)

With kind regards,
Chris

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEAREIAAYFAk/Q33UACgkQoWM1JLkHou24rwCfZt2sBwrCefbEhm5pmRz7ZEVx
zcoAn126ZKO+ceHnRkrhExfBITyJJrEO
=larE
-----END PGP SIGNATURE-----

# Brendan Eich (13 years ago)

This is not a candidate for the core language standard, ECMA-262. Even E4X, ECMA-357, a standard that failed to win adoption in browsers other than Firefox, cannot validate against schema.

This is where you want a JS library. There are many choices, although I'm no XML expert:

www.google.com/search?q=XSD+validation+in+JS&ie=utf-8&oe=utf

This is not a candidate for the core language standard, ECMA-262. Even 
E4X, ECMA-357, a standard that failed to win adoption in browsers other 
than Firefox, cannot validate against schema.

This is where you want a JS library. There are many choices, although 
I'm no XML expert:

https://www.google.com/search?q=XSD+validation+in+JS&ie=utf-8&oe=utf-8

/be

Christian Mayer wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Developing a ECMAScript based rich application I came across the
> problem to validate a XML based config file against a XSD to be able
> to leave out error handling during the config file processing in my code.
>
> But it seems there's no standardized way to it...
>
> Did I miss something or is such a fundamental building block really
> missing? (Could it be added to the standard?)
>
> With kind regards,
> Chris
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> iEYEAREIAAYFAk/Q33UACgkQoWM1JLkHou24rwCfZt2sBwrCefbEhm5pmRz7ZEVx
> zcoAn126ZKO+ceHnRkrhExfBITyJJrEO
> =larE
> -----END PGP SIGNATURE-----
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>

# Christian Mayer (13 years ago)

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

Thanks for the quick answer!

Am 07.06.2012 20:28, schrieb Brendan Eich:

This is not a candidate for the core language standard, ECMA-262.

OK. If ECMA-262 is only about core and not the (default) library - where could I ask then? Which body takes care about the libaray?

This is where you want a JS library. There are many choices, although I'm no XML expert:

www.google.com/search?q=XSD+validation+in+JS&ie=utf-8&oe=utf-8

Even

there it looks more and more like a big, open toppic that many stumbled upon and noone could solve. The best solution so far seems to validate on the server and give that result back via AJAX, which is quite disappointing...

Thanks, Chris

PS: Of course you could write an validator in JavaScript and include that as an external library. But I fear that would create a huge overhead - especialls as I assume that browsers usually have a validator already included which could be made visible to the JS interpreter. The MSXML is already going that way - but it's not cross platform.

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux)

iEYEAREIAAYFAk/R56EACgkQoWM1JLkHou2b7wCfbMuqZLOFwKH0zsuRi7C0PnkP 2boAn2fCb7uWoSZTBcPvOjBkgnOMD3TL =tx2D -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Thanks for the quick answer!

Am 07.06.2012 20:28, schrieb Brendan Eich:
> This is not a candidate for the core language standard, ECMA-262.

OK. If ECMA-262 is only about core and not the (default) library -
where could I ask then? Which body takes care about the libaray?

> This is where you want a JS library. There are many choices,
> although I'm no XML expert:
> 
> https://www.google.com/search?q=XSD+validation+in+JS&ie=utf-8&oe=utf-8

Even
> 
there it looks more and more like a big, open toppic that many
stumbled upon and noone could solve. The best solution so far seems to
validate on the server and give that result back via AJAX, which is
quite disappointing...

Thanks,
Chris

PS: Of course you could write an validator in JavaScript and include
that as an external library. But I fear that would create a huge
overhead - especialls as I assume that browsers usually have a
validator already included which could be made visible to the JS
interpreter. The MSXML is already going that way - but it's not cross
platform.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEAREIAAYFAk/R56EACgkQoWM1JLkHou2b7wCfbMuqZLOFwKH0zsuRi7C0PnkP
2boAn2fCb7uWoSZTBcPvOjBkgnOMD3TL
=tx2D
-----END PGP SIGNATURE-----

# David Bruant (13 years ago)

Le 08/06/2012 13:53, Christian Mayer a écrit :

Thanks for the quick answer!

Am 07.06.2012 20:28, schrieb Brendan Eich:

This is not a candidate for the core language standard, ECMA-262. OK. If ECMA-262 is only about core and not the (default) library - where could I ask then? Which body takes care about the libaray?

My guess would be the WHATWG [1] or public web apps [2].

This is where you want a JS library. There are many choices, although I'm no XML expert:

www.google.com/search?q=XSD+validation+in+JS&ie=utf-8&oe=utf-8 Even there it looks more and more like a big, open toppic that many stumbled upon and noone could solve.

I came to the same conclusion when I had that same problem a couple of years ago. I'm not very surprised it hasn't changed.

The best solution so far seems to validate on the server and give that result back via AJAX, which is quite disappointing...

Thanks, Chris

PS: Of course you could write an validator in JavaScript and include that as an external library. But I fear that would create a huge overhead

XSD is indeed a complicated spec and would require quite some code :-)

especialls as I assume that browsers usually have a validator already included which could be made visible to the JS interpreter

Is it the case in Firefox or Chrome? I would guess not, but I don't know them that much.

The MSXML is already going that way - but it's not cross platform.

Indeed. Web technologies have not taken the XML turn a lot of people expected 5-10 years ago.

David

[1] lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org [2] lists.w3.org/Archives/Public/public-webapps

Le 08/06/2012 13:53, Christian Mayer a écrit :
> Thanks for the quick answer!
>
> Am 07.06.2012 20:28, schrieb Brendan Eich:
>> This is not a candidate for the core language standard, ECMA-262.
> OK. If ECMA-262 is only about core and not the (default) library -
> where could I ask then? Which body takes care about the libaray?
My guess would be the WHATWG [1] or public web apps [2].

>> This is where you want a JS library. There are many choices,
>> although I'm no XML expert:
>>
>> https://www.google.com/search?q=XSD+validation+in+JS&ie=utf-8&oe=utf-8
> Even there it looks more and more like a big, open toppic that many
> stumbled upon and noone could solve.
I came to the same conclusion when I had that same problem a couple of 
years ago. I'm not very surprised it hasn't changed.

> The best solution so far seems to
> validate on the server and give that result back via AJAX, which is
> quite disappointing...
>
> Thanks,
> Chris
>
> PS: Of course you could write an validator in JavaScript and include
> that as an external library. But I fear that would create a huge
> overhead
XSD is indeed a complicated spec and would require quite some code :-)

> especialls as I assume that browsers usually have a
> validator already included which could be made visible to the JS
> interpreter
Is it the case in Firefox or Chrome? I would guess not, but I don't know 
them that much.

> The MSXML is already going that way - but it's not cross
> platform.
Indeed. Web technologies have not taken the XML turn a lot of people 
expected 5-10 years ago.

David

[1] http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org
[2] http://lists.w3.org/Archives/Public/public-webapps/

# Brendan Eich (13 years ago)

David Bruant wrote:

Indeed. Web technologies have not taken the XML turn a lot of people expected 5-10 years ago.

I'd go further. XML failed. We founded the whatwg in 2004 (Mozilla, Opera, Apple) because the w3c was chasing a utopian, replace-the-web, XML dream. We saw that going nowhere; we were right.

XML failed on the client and the web, but it's still used a bit here and there, and it is used server-side and in Enterprise "dark matter" that does not radiate onto the public web. I'm not dismissing those use-cases but they've had to make do with a library (native code or self-hosted). That's the current likely solution and Ecma TC39 can't really help.

David Bruant wrote:
> Indeed. Web technologies have not taken the XML turn a lot of people 
> expected 5-10 years ago. 

I'd go further. XML failed. We founded the whatwg in 2004 (Mozilla, 
Opera, Apple) because the w3c was chasing a utopian, replace-the-web, 
XML dream. We saw that going nowhere; we were right.

XML failed on the client and the web, but it's still used a bit here and 
there, and it is used server-side and in Enterprise "dark matter" that 
does not radiate onto the public web. I'm not dismissing those use-cases 
but they've had to make do with a library (native code or self-hosted). 
That's the current likely solution and Ecma TC39 can't really help.

/be

# David Bruant (13 years ago)

Le 08/06/2012 16:02, Brendan Eich a écrit :

David Bruant wrote:

Indeed. Web technologies have not taken the XML turn a lot of people expected 5-10 years ago.

I'd go further. XML failed. We founded the whatwg in 2004 (Mozilla, Opera, Apple) because the w3c was chasing a utopian, replace-the-web, XML dream. We saw that going nowhere; we were right. From where I stand, I would say that you had no choice because of market pressure not to break the (existing) web, but I guess that also counts as "we saw that going nowhere" ;-)

From a web dev perspective, I don't think XML would have been worse or better. People would have created an ecosystem of tools to work around the existing technologies. This is what happened with the DOM. This is what's happening with HTML and all the templating frameworks popping up recently. This is what's happening with CSS and CSS preprocessors, etc.

XML failed on the client and the web, but it's still used a bit here and there, and it is used server-side and in Enterprise "dark matter" that does not radiate onto the public web. I'm not dismissing those use-cases but they've had to make do with a library (native code or self-hosted).

I've had some experience with XML technology and writing web sites without using them. My take on the matter is that XSD, XSLT and the likes are interesting technologies, but they are complicated and yet another language to learn. I understand writing the validations/transformations I need in the server-side language I already know in a couple of lines is more attractive than learning a whole new rich language + binding API. I also need to maintain a codebase written in one language.

Le 08/06/2012 16:02, Brendan Eich a écrit :
> David Bruant wrote:
>> Indeed. Web technologies have not taken the XML turn a lot of people 
>> expected 5-10 years ago. 
>
> I'd go further. XML failed. We founded the whatwg in 2004 (Mozilla, 
> Opera, Apple) because the w3c was chasing a utopian, replace-the-web, 
> XML dream. We saw that going nowhere; we were right.
 From where I stand, I would say that you had no choice because of 
market pressure not to break the (existing) web, but I guess that also 
counts as "we saw that going nowhere" ;-)

 From a web dev perspective, I don't think XML would have been worse or 
better. People would have created an ecosystem of tools to work around 
the existing technologies. This is what happened with the DOM. This is 
what's happening with HTML and all the templating frameworks popping up 
recently. This is what's happening with CSS and CSS preprocessors, etc.


> XML failed on the client and the web, but it's still used a bit here 
> and there, and it is used server-side and in Enterprise "dark matter" 
> that does not radiate onto the public web. I'm not dismissing those 
> use-cases but they've had to make do with a library (native code or 
> self-hosted).
I've had some experience with XML technology and writing web sites 
without using them.
My take on the matter is that XSD, XSLT and the likes are interesting 
technologies, but they are complicated and yet another language to learn.
I understand writing the validations/transformations I need in the 
server-side language I already know in a couple of lines is more 
attractive than learning a whole new rich language + binding API. I also 
need to maintain a codebase written in one language.

David

# Brendan Eich (13 years ago)

David Bruant wrote:

From a web dev perspective, I don't think XML would have been worse or better. People would have created an ecosystem of tools to work around the existing technologies. This is what happened with the DOM. This is what's happening with HTML and all the templating frameworks popping up recently. This is what's happening with CSS and CSS preprocessors, etc.

You are forgetting a couple of crucial facts:

XML yellow screen of death. HTML has error recovery standardized (de-facto prior to HTML5), tolerates recurrent patterns of human error nesting tags, etc. XML does not. We can debate whether tools would help, but see next item.
IE loaded the commonly-typed XHTML of the day, text/xhtml, using its error-correcting parser, not a strict and stringent XML parser, and IE had dominant market share (85-90%).

The two in combination meant there was no way XML as practiced on the web (you could find it then and still can) would validate.

David Bruant wrote:
> From a web dev perspective, I don't think XML would have been worse or 
> better. People would have created an ecosystem of tools to work around 
> the existing technologies. This is what happened with the DOM. This is 
> what's happening with HTML and all the templating frameworks popping 
> up recently. This is what's happening with CSS and CSS preprocessors, 
> etc. 

You are forgetting a couple of crucial facts:

1. XML yellow screen of death. HTML has error recovery standardized 
(de-facto prior to HTML5), tolerates recurrent patterns of human error 
nesting tags, etc. XML does not. We can debate whether tools would help, 
but see next item.

2. IE loaded the commonly-typed XHTML of the day, text/xhtml, using its 
error-correcting parser, not a strict and stringent XML parser, and IE 
had dominant market share (85-90%).

The two in combination meant there was no way XML as practiced on the 
web (you could find it then and still can) would validate.

/be