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: Re: [legaldocml] RE : [legaldocml] Acts and bills


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,

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

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