From: Eric Fayolle Date: Thu, 21 Nov 2019 12:48:49 +0000 (+0100) Subject: maj doc mapping xsd X-Git-Tag: V200520bis~106^2 X-Git-Url: http://git.salome-platform.org/gitweb/?a=commitdiff_plain;h=15d8cddb6d11047b8497e263f1c8333e8d9b6826;p=tools%2Feficas.git maj doc mapping xsd --- diff --git a/Tests/MappingAccasXsd/cata_1.py b/Tests/MappingAccasXsd/cata_1.py index b15c858b..8e43daf4 100644 --- a/Tests/MappingAccasXsd/cata_1.py +++ b/Tests/MappingAccasXsd/cata_1.py @@ -1,3 +1,6 @@ +# coding: utf-8 -*- +# + #import os #import types #monFile=os.path.abspath(__file__) @@ -5,7 +8,12 @@ from Accas import * import types +#type UserASSD class User_Data(UserASSD): pass +#type ASSD +class Mesh(ASSD): pass +#type UserASSD +class MeshBis(UserASSD): pass #Be careful when modidying the order/names od the test_simp since they are used bye the documentation xsd_mapping.rst #beginJdC @@ -29,11 +37,47 @@ Test_proc_1 = PROC(nom = 'Test_proc_1', # test_simp_5 = SIMP(statut='o', typ='C' , defaut=('RI',1,0)), # test_simp_5 = SIMP(statut='o', typ='C' , defaut=3+2j), test_simp_6 = SIMP(statut='o' , typ='TXM' , max="**",min=3), +#TODO : Creer un type XSD pour les repertoires. test_simp_7_1 = SIMP(statut='o' , typ='Repertoire' ), test_simp_7_2 = SIMP(statut='o' , typ='Fichier' ), - test_simp_7_3 = SIMP(statut='o' , typ='FichierOuRepertoire' ), + test_simp_7_3 = SIMP(statut='o' , typ='FichierOuRepertoire', ), +#BUG : Le deuxième filtre n'est pas pris en compte + test_simp_7_4 = SIMP(statut='o' , typ=('Fichier', 'XML Files(*.xml);;XSD Files(*.xsd)') ), +#TODO : Generer les types de nom de fichier avec regexp + test_simp_7_5 = SIMP(statut='o' , typ=('Repertoire','Test Files(Test*)')), +#BUG?: La boîte de dialogue QT ne propose pas de définir un nouveau fichier en utilisant le path de la boîte de dialogue +#Le nom de fichier par défaut n'est pas prise en compte + test_simp_7_6 = SIMP(statut='o' , typ=('FichierNoAbs','XML Files(*.xml);;XSD Files(*.xsd)','myFile1.xml')), test_simp_8_1 = SIMP(statut='o' , typ=(User_Data,'createObject')), test_simp_8_2 = SIMP(statut='o' , typ=User_Data), ) + +Test_proc_2 = PROC(nom = 'Test_proc_2',) +Test_oper_1 = OPER(nom = 'Test_oper_1', sd_prod=Mesh,) + +#Usecase 1 : Il est possible de créer plusieurs maillages à la racine +ConstructMesh = OPER(nom = 'ConstructMesh', sd_prod=Mesh, + dimension = SIMP(typ='I', into=[1,2,3]), + listOfEntities = SIMP(typ='I', max='**'),) +#Usecase 1 : Chaque champ crée à la racine référence un maillage par son nom +# (il faut qu'il soit crée au préalable) +MyField = PROC(nom='MyField', + onMesh = SIMP(statut='o',typ=Mesh),) + + +#Usecase 2 : Il est possible de créer plusieurs maillages dans une me structure nommée meshes +Meshes = PROC(nom = 'Meshes', + mesh = FACT(max='**', + meshname = SIMP(typ=(MeshBis,'createObject')), + dimension = SIMP(typ='I', into=[1,2,3]), + listOfEntities = SIMP(typ='I', max='**'), + ), + )#Meshes +# #Usecase 1 : Chaque champ crée à la racine référence un maillage par son nom +# # (il faut qu'il soit crée au préalable) +MyFieldBis = PROC(nom='MyFieldBis', + onMesh = SIMP(typ=MeshBis), + ) + #endJdC diff --git a/Tests/MappingAccasXsd/xml.xsd b/Tests/MappingAccasXsd/xml.xsd new file mode 100644 index 00000000..bd291f3d --- /dev/null +++ b/Tests/MappingAccasXsd/xml.xsd @@ -0,0 +1,286 @@ + + + + + + +
+

About the XML namespace

+ +
+

+ This schema document describes the XML namespace, in a form + suitable for import by other schema documents. +

+

+ See + http://www.w3.org/XML/1998/namespace.html and + + http://www.w3.org/TR/REC-xml for information + about this namespace. +

+

+ Note that local names in this namespace are intended to be + defined only by the World Wide Web Consortium or its subgroups. + The names currently defined in this namespace are listed below. + They should not be used with conflicting semantics by any Working + Group, specification, or document instance. +

+

+ See further below in this document for more information about how to refer to this schema document from your own + XSD schema documents and about the + namespace-versioning policy governing this schema document. +

+
+
+ + + + + + +
+ +

lang (as an attribute name)

+

+ denotes an attribute whose value + is a language code for the natural language of the content of + any element; its value is inherited. This name is reserved + by virtue of its definition in the XML specification.

+ +
+
+

Notes

+

+ Attempting to install the relevant ISO 2- and 3-letter + codes as the enumerated possible values is probably never + going to be a realistic possibility. +

+

+ See BCP 47 at + http://www.rfc-editor.org/rfc/bcp/bcp47.txt + and the IANA language subtag registry at + + http://www.iana.org/assignments/language-subtag-registry + for further information. +

+

+ The union allows for the 'un-declaration' of xml:lang with + the empty string. +

+
+ + + + + + + + + + + + + + + + +
+ +

space (as an attribute name)

+

+ denotes an attribute whose + value is a keyword indicating what whitespace processing + discipline is intended for the content of the element; its + value is inherited. This name is reserved by virtue of its + definition in the XML specification.

+ +
+ + + + + + + + + + + + +
+ +

base (as an attribute name)

+

+ denotes an attribute whose value + provides a URI to be used as the base for interpreting any + relative URIs in the scope of the element on which it + appears; its value is inherited. This name is reserved + by virtue of its definition in the XML Base specification.

+ +

+ See http://www.w3.org/TR/xmlbase/ + for information about this attribute. +

+
+ + + + + + + +
+ +

id (as an attribute name)

+

+ denotes an attribute whose value + should be interpreted as if declared to be of type ID. + This name is reserved by virtue of its definition in the + xml:id specification.

+ +

+ See http://www.w3.org/TR/xml-id/ + for information about this attribute. +

+
+ + + + + + + + + + + + + +
+ +

Father (in any context at all)

+ +
+

+ denotes Jon Bosak, the chair of + the original XML Working Group. This name is reserved by + the following decision of the W3C XML Plenary and + XML Coordination groups: +

+
+

+ In appreciation for his vision, leadership and + dedication the W3C XML Plenary on this 10th day of + February, 2000, reserves for Jon Bosak in perpetuity + the XML name "xml:Father". +

+
+
+
+ + + + + +
+

About this schema document

+ +
+

+ This schema defines attributes and an attribute group suitable + for use by schemas wishing to allow xml:base, + xml:lang, xml:space or + xml:id attributes on elements they define. +

+

+ To enable this, such a schema must import this schema for + the XML namespace, e.g. as follows: +

+ 
+          <schema . . .>
+           . . .
+           <import namespace="http://www.w3.org/XML/1998/namespace"
+                      schemaLocation="http://www.w3.org/2001/xml.xsd"/>
+
+

+ or +

+ 
+           <import namespace="http://www.w3.org/XML/1998/namespace"
+                      schemaLocation="http://www.w3.org/2009/01/xml.xsd"/>
+
+

+ Subsequently, qualified reference to any of the attributes or the + group defined below will have the desired effect, e.g. +

+ 
+          <type . . .>
+           . . .
+           <attributeGroup ref="xml:specialAttrs"/>
+
+

+ will define a type which will schema-validate an instance element + with any of those attributes. +

+
+
+ + + + + +
+

Versioning policy for this schema document

+
+

+ In keeping with the XML Schema WG's standard versioning + policy, this schema document will persist at + + http://www.w3.org/2009/01/xml.xsd. +

+

+ At the date of issue it can also be found at + + http://www.w3.org/2001/xml.xsd. +

+

+ The schema document at that URI may however change in the future, + in order to remain compatible with the latest version of XML + Schema itself, or with the XML namespace itself. In other words, + if the XML Schema or XML namespaces change, the version of this + document at + http://www.w3.org/2001/xml.xsd + + will change accordingly; the version at + + http://www.w3.org/2009/01/xml.xsd + + will not change. +

+

+ Previous dated (and unchanging) versions of this schema + document are at: +

+ +
+
+ + + + diff --git a/docCataWriter/oper_and_proc.rst b/docCataWriter/oper_and_proc.rst index 3376e8b2..fc134927 100644 --- a/docCataWriter/oper_and_proc.rst +++ b/docCataWriter/oper_and_proc.rst @@ -61,8 +61,8 @@ Defining a concept type / user type ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A OPER definition agregate hierarchical data in order to express a coherent part of your modelisation. -Despite an PROC it produce a new data that you can reuse in further defintion. -A OPER may also be seen as a fuction call with more or less complex parameters which return a new +Despite a PROC, an OPER produces a new data that you can reuse in further defintion. +A OPER may also be seen as a fuction call with more or less complex parameters which return a new one. To describe an OPER , you have first to describe a user-defined type of concept. Declarations appears at the beginning of the catalogs. User classes inherits from ASSD. Most of the time the pass statement is all you need to write. diff --git a/docCataWriter/xsd_mapping.rst b/docCataWriter/xsd_mapping.rst index e7197f99..f268f8bd 100644 --- a/docCataWriter/xsd_mapping.rst +++ b/docCataWriter/xsd_mapping.rst @@ -359,12 +359,14 @@ And the element declaration : .. note:: It could be useful to define a specic xsd type for using a well-known type for managing files and directories. -SIMP for UserASSD type +SIMP of UserASSD type ~~~~~~~~~~~~~~~~~~~~~~ -An SIMP may be type with a user defined type. Depending on the way you defined the SIMP you can either create it or refer to it. This is the same notion as :ref:`Defining a concept type ` for an OPER but defined an used where ever you like. +An SIMP may have a user defined type. +Depending on the way you declare the SIMP, you can either create a new data or refer to a previoulsy created one. - -Here is an example for a SIMP with user type *User_Data* : +Declaration of an UserASSD type SIMP +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Here is a declaration example for a SIMP with user type *User_Data* : The *SIMP* declaration is : @@ -379,14 +381,22 @@ The *SIMP* declaration is : :start-at: test_simp_8_1 :end-at: test_simp_8_1 +The *UserASSD* class declared this way is quite the same notion as using an *ASSD* class in an *OPER* command (:ref:`Defining a concept type `). The *UserASSD* differs from an ASSD by : + * the *UserASSD* *SIMP* can be declared where ever you like in the catalog (not just at first level like for an *OPER*) + * it is assummed that all the necessary data for contructing objects of *UserASSD* type are declared in the catalog ( objects of *ASSD* are assumed to be created thanks to the help of some *OPER* parameters but not exactly with that paramters... ) + You get the xsd type : - + +.. todo:: Correct the mapping (see OPER) + .. literalinclude:: ../Tests/MappingAccasXsd/cata_1_genere.xsd :language: xml :start-at: name="T_test_simp_8_1" :end-at: /xs:simpleType And the element declaration : + +.. todo:: Correct the mapping (see OPER) .. literalinclude:: ../Tests/MappingAccasXsd/cata_1_genere.xsd :language: xml @@ -394,7 +404,10 @@ And the element declaration : :start-at: name="test_simp_8_1" :end-at: name="test_simp_8_1" -The *SIMP* reference is : +Referencing a UserASSD type SIMP +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The *SIMP* reference is done this way: .. literalinclude:: ../Tests/MappingAccasXsd/cata_1.py :language: python @@ -402,7 +415,11 @@ The *SIMP* reference is : :start-at: test_simp_8_2 :end-at: test_simp_8_2 +Note the User_Data type given to the *typ* attribute. + You get the xsd type : + +.. todo:: Correct the mapping (see OPER) .. literalinclude:: ../Tests/MappingAccasXsd/cata_1_genere.xsd :language: xml @@ -410,14 +427,14 @@ You get the xsd type : :end-at: /xs:simpleType And the element declaration : + +.. todo:: Correct the mapping (see OPER) .. literalinclude:: ../Tests/MappingAccasXsd/cata_1_genere.xsd :language: xml :dedent: 2 :start-at: name="test_simp_8_2" :end-at: name="test_simp_8_2" - -.. note:: Modifier la génération pour s'adapter à celle de l'OPER. SIMP for complex type {'C'} ~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -468,42 +485,105 @@ The root element declaration is : The name of the element comes from the *code* parameter previously defined. You find all the element declarations that come from all the *PROC* / *OPER* declared in the catalog. +.. note:: For generate drivers with PyXB, it's a really bad idea to define xsd **element** with **maxOccurs** > 1 in a **xs:choice** with a **maxOccurs** == 'unbounded'. Despite the generate code is correct, it produce a python class unusable since the PyXB Finite Automate with Counter can't decide from which schema component two elements of the same type comes from. This ambighuity interrupt the xml mapping of your python object. + +.. note:: TODO : We have to explain the way we use the schema namespaces. + The OPER command ~~~~~~~~~~~~~~~~ -The *OPER* declaration is : +The *OPER* command returns an *ASSD* type (not a *UserASSD* ). An *ASSD* type provides the ability to declare and use a new class in a eficas catalog. After having declared the new typename *ASSD* : .. literalinclude:: ../Tests/MappingAccasXsd/cata_1.py :language: python - :start-at: class User_Data - :end-at: class User_Data + :start-at: class Mesh + :end-at: class Mesh +The *OPER* command describes a way to create user type instances : + .. literalinclude:: ../Tests/MappingAccasXsd/cata_1.py :language: python - :start-at: Test_oper_1 - :end-at: Test_oper_1 + :start-at: ConstructMesh + :end-at: ,) + You get the xsd type : .. literalinclude:: ../Tests/MappingAccasXsd/cata_1_genere.xsd :language: xml - :start-at: name="T_Test_oper_1" + :start-at: name="T_ConstructMesh" :end-at: /xs:complexType -And the element declaration : +.. note:: + * The **attribute** 'name' is used in the xml dataset to hold the name of the user data *Mesh*. + * The two xsd **attribute** 'accasType' and 'typeUtilisateur' are for eficas internal use + +The element declaration is : .. literalinclude:: ../Tests/MappingAccasXsd/cata_1_genere.xsd :language: xml :dedent: 2 - :start-at: name="Test_oper_1" - :end-at: name="Test_oper_1" + :start-at: name="ConstructMesh" + :end-at: name="ConstructMesh" +If you want to declare in the catalog that a specific data of the dataset is a reuse of an already produced data by an *OPER*, you have to declare it within an SIMP. This SIMP must have the *typ* attribute equals to the *sd_prod* attribute value of the corresponding *OPER* : + +.. literalinclude:: ../Tests/MappingAccasXsd/cata_1.py + :language: python + :start-at: MyField + :end-at: ,) +You get the xsd types : + +.. literalinclude:: ../Tests/MappingAccasXsd/cata_1_genere.xsd + :language: xml + :start-at: name="T_MyField" + :end-at: /xs:complexType + +.. todo:: Revisit the statut attribute use, here if you don't set statut='o' you have **minOccurs** == 0 + +and + +.. literalinclude:: ../Tests/MappingAccasXsd/cata_1_genere.xsd + :language: xml + :start-at: name="T_onMesh" + :end-at: /xs:simpleType + + +Concerning the element declaration : + +.. literalinclude:: ../Tests/MappingAccasXsd/cata_1_genere.xsd + :language: xml + :dedent: 2 + :start-at: name="MyField" + :end-at: name="MyField" + +The way we choose to map the *OPER* to xsd allows users to create a cross reference system using name of producted structure in their dataset. + +.. todo:: : Generate a schema validation rule to check that a name used as a reference is unique and exists in the corresponding object, we have to add in the root element declaration the following code : + +.. code-block:: xml + + + + + + + + + + + +.. note:: PyXB doesn't care about these rules, it relies on the sax/dom parsers capabilities. By default, using the libxml library, these checks are not perform. Anyway it's always possible to fully validate xml datasets by using a parser which have this kind of capability. + +.. todo:: PyXB doesn't automaticaly create links between the objects using the ref name contract. Either the user have to recrate the links or we have to provide a PyXB extension to do so. The PROC command ~~~~~~~~~~~~~~~~ +The *PROC* command agregates a first level coherent set of data. + The *PROC* declaration is : .. literalinclude:: ../Tests/MappingAccasXsd/cata_1.py @@ -526,9 +606,38 @@ And the element declaration : :start-at: name="Test_proc_2" :end-at: name="Test_proc_2" +Using an SIMP UserASSD in a PROC or a FACT +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Here is a *PROC* declaration using an SIMP UserASSD : + +.. literalinclude:: ../Tests/MappingAccasXsd/cata_1.py + :language: python + :start-at: class MeshBis + :end-at: class MeshBis + +.. literalinclude:: ../Tests/MappingAccasXsd/cata_1.py + :language: python + :start-at: Meshes + :end-at: #Meshes + +You get the xsd type : + +.. literalinclude:: ../Tests/MappingAccasXsd/cata_1_genere.xsd + :language: xml + :start-at: name="T_Meshes" + :end-at: /xs:complexType + +And the element declaration : + +.. literalinclude:: ../Tests/MappingAccasXsd/cata_1_genere.xsd + :language: xml + :dedent: 2 + :start-at: name="Meshes" + :end-at: name="Meshes" -Understanding the XSD mapping for FACT and BLOCK +Understanding the XSD mapping for FACT and BLOC ________________________________________________