Dear Tom and All,
now I am not Fabio or Monica, who designed Akoma Ntoso, I am not an expert of XML either and so I should probably stop here :-) but since I am not wise also ...;-) let me try to contribute with a bit of history and my understanding of what makes Akoma Ntoso good but also at times difficult to appreciate.
The context where Akoma Ntoso was born and the task that we assigned to Fabio and Monica, was first and foremost a schema that could have dealt effectively with the different documents types, the different legal traditions and their "exceptions" that as we know are the in fact ... the rule.
When Fabio and Monica took up, what was indeed a "challenge", it was early 2006 and we had already a prototype schema which was first released in early 2005.
Fabio and Monica (from now on F&M and please keep in mind that I am not an expert but one that had to struggle to justify to many people what we were doing) could have taken what I can say a traditional approach and just deliver a "schema proliferation" to cover with different schemata all the possible documents types, the possible traditions etc. Many countries have taken this road and they are still adding new schemata with all the challenges that this bring in terms maintainability and tools.
The approach of F&M, based on their long experience to deal the mess of different legal ecosystem, was "simple", not a "tradional-schema" but, I hope F&M will not ... what we can call a "meta-schema" that is Akoma Ntoso.
Through the years one of the main challenges that we had, I am not talking about the technical ones, was to win over the natural suspicion that Akoma Ntoso could not possibly "fit my data"! The fear has always been that Akoma Ntoso "secret" aim was to "standardise" how documents are made, to reduce the different individualities, to slave "my data" to the will of Akoma Ntoso.
This natural resistance to Akoma Ntoso was mainly fed by the assumption that Akoma Ntoso was a "schema" in the traditional way. That Akoma Ntoso was a "master" that dictates how a law should be marked up, what should be its structure, et. et.
That was also my "fear", I have to say, and it took me a while before appreciating the great work of F&M. In my understanding of Akoma Ntoso, that I hope may shed also some light for you too, Akoma Ntoso is not as "schema-old-school", is like a Lego box of building blocks, you have windows, doors, corners, tiles, roofs etc. for you to freely use.
Lego bricks are used all over the world, by different children to build totally different houses. Lego bricks do the limit the individuality, on the contrary (to a certain extend since ... but this would be material for another e-mails) they provide the "bricks" to express it.
Akoma Ntoso is a Lego box of legal XML tags for people of different traditions and languages to build their own schema. It does not limit your creativity, it does not impose you to markup ... if not what you want. You may say but ... isn't this too little, should we "standardise" more ... we all know that it may not work and having common bricks is already a huge step forward, I would say.
May be all the above was all very clear to you. If that is the case, my apologies, I just wanted to share my personal struggle to eventually come to appreciate the originality of Akoma Ntoso and the potentiality that it may have.
This is NOT to say that is perfect or that there are not probably many things to fix and to improve. That has to be clear. I personally feel that thanks all your expertise and experiences we will eventually have a better Akoma Ntoso ... for all enjoy marking up, what they wish, the way the wish ... of course in an Akoma Ntoso compliant way :-)
Hope to have been of some use. Sure F&M will address the technical issues.
ciao
Flavio
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Chief Technical Adviser Africa i-Parliaments Action PlanUNDESA - Nairobi - Kenya
Mobile : +254-733-638 298 Telephone : +254-20-374 9892/3
Fax : +254-20-374 9894
On 20 May 2012 16:49, Thomas R. Bruce
<tom@liicornell.org> wrote:
Folks:
I should probably be a little more explicit about the perspective that leads me to raise some of the questions that I've been asking. I'm anxious for AkomaNtoso to be a well-developed and widely-adopted standard, and I believe that in order for that to happen some bulletproofing is needed. Some of that need is technical, and some of it is essentially political. I believe that AkomaNtoso was conceived originally as a standard to be implemented in jurisdictions with little or no prior commitment to any XML or SGML standard, and largely in jurisdictions where it would be inserted into the process at inception -- that is, with legislative and regulatory drafters in a setting where it would then form a lifecycle system for legislative documents from cradle to grave.
Are there any differences between what you'd do in a cradle-to-grave system and what you'd do in a post-hoc publishing system? There's reason to be suspicious, just as there always is when people start asserting exceptionalism in a standards-building process. Our job here is, in some sense, to discover and sanctify similarities, and that's a difficult process that's hard for people used to doing things their own way to wrap their heads around. But there are exceptions that are legitimate. And unfortunately, post-hoc publishers have to accept them, along with a host of other suboptimal ways of doing things.
All that to say that I think we need to pay careful attention to problems of modeling and encoding things as we find them in the wild, where they are often a mess. We look for commonalities and simplicity, but we often have to introduce some complexity in order to cover semi-exceptional cases. And potential adopters are always very quick to say "that doesn't look like *my* data".
A second question of design philosophy has to do with the ultimate product. I got to thinking: is our goal here *only* the simple encoding of what the legislature said, or are we also trying to make the XML document a point of departure for a wider range of use cases? That becomes a confusing question because (whether we are aware of it or not) the use cases that we have at the back of our minds when we're working on these things are mostly about search, and the question then becomes whether we're encoding textual features we can use to make facets for searching. There are other questions we might ask, having to do with applications in which a snippet of legislative text is embedded in something else (say, a web page that says "here is the most current version of Section X"). Or post-hoc validation of documents that have been transformed into AkomaNtoso and not born Akomish. And so on.
Which brings me to my Qu(estion|ibble) of the Week: the business of using arbitrary, locally determined strings as names for elements that encode structure. It seems to me that this creates a situation in which documents can't be validated, but I may be confused, so:
a) If a particular AN user/publisher decides to enforce a hierarchy of elements in which , eg., "subtitle" is only legitimate within "title", or "section" is only legitimate within "part", how is that done?
b) The million-dollar question for the US Code: if the hierarchy of elements is different within one partition of a corpus from what it is within others, can AN accomodate that and still support validation for the corpus as a whole? Here's why I ask. In most Titles of the US Code, the Part element would be contained within the Chapter element. That isn't true in Title 38; it's the other way around. Could AN accomodate this, and still validate the Code as a whole? (that's not the only such variation, by the way, and the CFR introduces a whole other can of worms, including "anonymous" levels and many, many exceptions to rules about what can be legitimate children of what).
If not, what would the objection be to a system like this: <level1 label="title"> and <level2 label="subtitle"> or just to be really wild and crazy <level n=1 label="title"> <level n=2 label="subtitle">? Less intuitive, sure, but a lot more flexible in what it maps to what, and how it can structure things and still validate.
I think I have more questions about how IDs work, but a first one would be ... are they essentially just opaque strings so far as AN is concerned? Some look like they embed structural semantics, at least for convenience/brain-compatibility.
All the best,
T.
--
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Thomas R. Bruce @trbruce
Director, Legal Information Institute
Cornell Law School
http://www.law.cornell.edu/ @liicornell
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
---------------------------------------------------------------------
To unsubscribe, e-mail: legaldocml-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: legaldocml-help@lists.oasis-open.org