OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

legaldocml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Modular Akoma Ntoso


Dear all, 

during this year's Developer Workshop in Ravenna, I have shown the audience the inner working of my tool to generate subschemas out of the modules of the Akoma Ntoso main schema. This presentation did not go as well as I hoped. Even though the tool worked pretty well and managed to produce the output that I promised, the facial expression of the audience, and of Grant foremost, where enough to make me ashamed of myself. 

Yes, I admit. Relying on a never-born schema language such as DTD++, having exactly ONE user in the world (myself) and building tools around and before the schema in DTD++ is NOT ELEGANT. Even if these tools worked perfectly (and god knows they do not), relying for the production of the final schema on a bad converter from an unknown language wrapped by a couple of stylesheets from a fake XML vocabulary is hard to justify. 

I am here enclosing a version of the modules fully expressed in XML Schema. The schema is extended with markup from another namespace, xmlns:m="http://docs.oasis-open.org/legaldocml/ns/modular/1.0"; , comprising exactly ONE element and ONE attribute: 

* Element <m:content> is placed where you want the list of active modules to be specified. Namely, in the comment at the beginning of the schema. 

* Attribute m:if is placed in any structure (element, attribute, type, group, etc.) whose inclusion in the subschema depends on the selection of a module. For instance,

> <xsd:element ref="act" m:if="legislativeDocs"/>


means that the definition of element "act" depends on the presence of "legislativeDocs" in the list of modules selected for inclusion in the subschema. 

Nothing else. I re-entered manually the full list of modules as present in the DTD++ schema into the XSD schema, and created a couple of utility XSLT stylesheets for them. 

The first, "transformModules.xsl", receives as a parameter a space separated list of selected modules, and generates a valid subschema by keeping all definitions associated to the core module and the modules explicitly specified in the parameter, and throwing away the rest. 

The second, "transformModules", creates an HTML document providing some visualization of the modules and their content, to have an easier mechanism to understand and debate about which modules we should provide, and what structures should end up in each. 

I am attaching all for your pleasure, hoping that you are willing to play a little bit with this, and provide me with comments and opinions and stuff. 

So, here I am, my head covered with ashes, asking for your benevolence. Ok, ok, Grant. You won this time. Yes, I have seen my faults, and I am amending. Please never look at me again with that expression, I could not stand it a second time. 

Ciao

Fabio


--

Fabio Vitali                                          The sage and the fool
Dept. of Informatics                                     go to their graves
Univ. of Bologna  ITALY                               alike in this respect:
phone:  +39 051 2094872                  both believe the sage to be a fool.
e-mail: fabio@cs.unibo.it                  Where, then, may wisdom be found?
http://vitali.web.cs.unibo.it/   Qi, "Neither Yes nor No", The codeless code

Attachment: modularAKNschema3.0.zip
Description: Zip archive



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]