Re: [legaldocml] RE : [legaldocml] Acts and bills

["Thomas R. Bruce" <tom@liicornell.org>]

Folks:

Regrettably, I will not be able to attend tomorrow's meeting because of 
some urgent family business.  I did want to weigh in again on this 
question of nomenclature.  I agree with Fabio that it is important for 
us to come to agreement and move on so as not to imperil the process of 
adoption where it is already underway. Unfortunately, though, we face a 
situation where the target audience for new adoptions is much more 
diverse in its use of nomenclature than we anticipated, and no less 
insistent on its importance than the creators of the original standard.  
I agree with Grant that, if we want adoption, we must defer to local 
usages.  The first piece of advice I ever got on doing client 
presentations was, "Don't present with made-up data, and never show a 
client field names they won't recognize".   It still holds.  There is, 
in the United States, a popular diet called the "South Beach Diet" 
(don't know if it's made it abroad yet).   Its creators say that it 
isn't a very good diet, scientifically, except in one respect: it is the 
only diet that people will actually follow.  That, it seems to me, is 
our situation.

I do think we could settle the matter by proliferating 
attributes/properties a little.  I would suggest the use of two 
attributes, abstract-type and localname, to resolve the difference. So, 
perhaps instead of documentType, just <document abstract_type="(set of 
abstract types)" localname="eg. non-binding resolution">.  I do think 
there needs to be some expansion of the set of abstract types.  
Alternatively, one might just add an additional "localname" attribute to 
the documentType  element.

Fabio will not find this a useful remark, but I think that part of what 
we're seeing here is a problem with the general idea of having specific 
element names designed to meet an original set of needs that has vastly 
expanded with more widespread adoption across multiple jurisdictions.  
Just as with the naming of hierarchical levels, I continue to prefer a 
more flexible approach that uses a generic element name such as 
"document" or "level" and supplements/specifies more narrowly with 
attributes such as "n" (for level number) and "localname" for whatever 
the legislature/body in question calls the thing when they're all at 
home around the dinner table.   I find this to be a much cleaner and 
more flexible approach than proliferating element names.  I expect that 
won't be a popular view, especially this late in the game, but we do 
have a problem with name recognition by adopters and it will continue to 
grow with the scope of adoption.

All the best,
Tb.

--
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Thomas R. Bruce @trbruce
Director, Legal Information Institute
Cornell Law School
http://www.law.cornell.edu/ @liicornell
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+