RE: Modular Akoma Ntoso

Dear all,

LOL, Fabio. You are forgiven for your transgression â this time.

Just out of curiosity. Today I noticed that the model for <ol> and <ul> are subtly different (yes, I have a very good use case that brought this into the picture â Iâm converting pre-existing text that has these lists deep in the middle of everything). The difference is that one requires a single <li> while the other doesnât. Is there a reason for this? Itâs largely harmless, but surprising.

-Grant

Sent from Mail for Windows 10

From: Fabio Vitali
Sent: Thursday, September 27, 2018 4:23 PM
To: Grant Vergottini
Cc: Monica Palmirani; legaldocml@lists.oasis-open.org; Luca Cervone
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

legaldocml message