Suite à une question pertinente d'un client, j'ai cherché à comprendre pour quelle raison un schéma XSD me semblant parfaitement valable me générait une erreur à l'insertion des données...
Une fois le problème isolé, j'ai pu effectuer le test suivant :
DROP TABLE TestXML
GO
DROP XML SCHEMA COLLECTION TestDateRestriction
GO
DROP XML SCHEMA COLLECTION TestDateRestrictionTimeZone
GO
CREATE XML SCHEMA COLLECTION TestDateRestriction
AS
'<?xml version="1.0" encoding="utf-8"?>
<xsd:schema targetNamespace="http://tempuri.org/TestDateRestriction.xsd" attributeFormDefault="unqualified" elementFormDefault="qualified" xmlns="http://tempuri.org/TestDateRestriction.xsd" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:element name="root">
<xsd:simpleType>
<xsd:restriction base="xsd:dateTime">
<xsd:pattern value=".+T[^Z+-\.]+" />
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
</xsd:schema>'
GO
CREATE XML SCHEMA COLLECTION TestDateRestrictionTimeZone
AS
'<?xml version="1.0" encoding="utf-8"?>
<xsd:schema targetNamespace="http://tempuri.org/TestDateRestriction.xsd" attributeFormDefault="unqualified" elementFormDefault="qualified" xmlns="http://tempuri.org/TestDateRestriction.xsd" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:element name="root">
<xsd:simpleType>
<xsd:restriction base="xsd:dateTime">
<xsd:pattern value=".+T[^+-\.]+Z" />
</xsd:restriction>
</xsd:simpleType>
</xsd:element></xsd:schema>'
GO
CREATE TABLE TestXML
(
IdTB INT IDENTITY(1, 1) NOT NULL
CONSTRAINT PK_TestXML PRIMARY KEY CLUSTERED,
XMLTB XML (DOCUMENT TestDateRestriction) NULL,
XMLTBTimeZone XML (DOCUMENT TestDateRestrictionTimeZone) NULL
)
GO
INSERT INTO TestXML (XMLTB) VALUES (N'<r:root xmlns:r="http://tempuri.org/TestDateRestriction.xsd">2005-03-22T08:35:00</r:root>')
GO
INSERT INTO TestXML (XMLTBTimeZone) VALUES (N'<r:root xmlns:r="http://tempuri.org/TestDateRestriction.xsd">2005-03-22T08:35:00Z</r:root>')
GO
Le résultat est le suivant : SQL Server 2005 n'autorise pas les dates sans spécification du flag Time Zone.
Or, dans le cadre des types DateTime, la norme XSD n'impose nullement la présence de l'indication TimeZone spécifiée dans la norme ISO 8601 comme le spécifie le W3C dans les spécifications suivantes : http://www.w3.org/TR/2005/WD-xpath-datamodel-20050211/#storing-timezones...
En revanche, l'exemple précédent prouve définitivement le choix de SQL Server de se conformer à la norme ISO. Cette information est d'ailleurs confirmée par cet article de la MSDN : http://msdn2.microsoft.com/en-us/library/ms345115.aspx#sql25xmlbp_topic3 (section "Using xs:datetime, xs:date and xs:time").
La seule question qui me reste à élucider est la raison de ce choix exigeant qui pose un problème de compatibilité : le XSD dont je dispose est imposé et partagé par de nombreux utilisateurs et ne peut donc pas être modifié...
2 commentaires:
Or, dans le cadre des types DateTime, la norme XSD n'impose nullement la présence de l'indication TimeZone spécifiée dans la norme ISO 8601 comme le spécifie le W3C dans les spécifications suivantes ...
Comme beaucoup d'informaticiens, vous confondez beaucoup de choses et en particulier "norme" et "standard". Une norme est un document formel déposé auprès d'un organisme normatif. Chaque pays est doté d'un organisme normatif national. En France c'est l'AFNOR. Aux USA c'est l'ANSI. Une norme peut être internationalisé c'est à dire déposé à l'ISO (Genève).
Une norme à force de loi pour celui qui dit l'utiliser. Ainsi un fabriquant qui se réclamerait en conformité à la norme XYZ et n'y serait pas peut être attaqué pour manquement aux règles de l'Art...
Certaines Loi renforcent encore la puissance de la norme en obligeant tout acteur d'un secteur bien précis a se conformer à telle ou telle norme. Exemple les véhicules automobiles (nombreuses normes répressives).
Notons que le label de qualité est un cran au dessus de la norme : c'est d'abord une norme mais on y rajoute un contrôle de conformité obligatoire et en cas de non respect il y a perte du label sans dédommangement possible (engagement unilatéral).
Il en va tout autrement des standards. Il s'agit d'un document dans lequel un consortium (par exemple les industriels de la télévision) déclarent élaborer un document de travail commun, auquel chaque acteur va pouvoir faire référence pour les éléments techniques qu'il l'intéresse. Ainsi il existe les standards PAL, SECAM et NTSC pour la TV couleur.
Il est donc clair qu'une norme est prépodérante devant un standard.
Or en matière informatique il existe un certain nombre de normes et beaucoup de standard. En particulier tout ce qui est né des RFC est faiblement normalisé alors que ce qui relève des bases de données relationnelles est fortement normalisé. Je vous invite à lire mon livre comme à parcourir mon site pour vous en convaincre.
http://sqlpro.developpez.com
Bonjour,
La problématique n'est pas de savoir s'il s'agit d'une norme ou d'un standard.
Effectivement, aucune norme n'existe concernant les schémas XSD qui est définitivement un standard. Il s'agit là d'un abus de langage que n'importe quelle personne aura bien évidemment isolé aisément, car la seule norme dont je parle - et qui est bien une norme internationale - est identifiée par son numéro : ISO 8601.
En l'occurence, ce qui me gêne n'est pas tant le non respect du standard tel qu'il est défini mais plutôt le fait que Microsoft a participé activement à l'élaboration de ce standard et en revendique même une part de la paternité. Dans ces conditions, pourquoi s'éloigner du standard choisi ?
A mon sens cet article était plus destiné à expliquer à certaines personnes rencontrant ce même problème la cause de ce dernier qu'à susciter un débat ergotique sur la différence entre les normes et les standards. D'ailleurs sans rapport avec un livre sur un sujet bien défini et sans ambiguité : les normes SQL...
Enregistrer un commentaire