FW: [legalxml-courtfiling] Preliminary List of "Roles" in LegalProceedings

John, My sentiments also, with an exception, my friend, to deferring this work to V2.0....
For V1.0, I believe the present course -- to the extent it does not adopt the W3C's Resource Description Framework from the outset -- is highly inimical to achieving our organization's goals and objectives.
The present methodology we've adopted by default appears to me to be yielding a set of haphazardly constructed DTDs for court records and court documents.
No information science is being applied at all, with the result that it is going to be more costly to the judicial branch of governments to implement supporting systems.
That is annoying to taxpayers in general, and I believe directly and undeniably diminishes our analytic abilities during our "war" on terror, and beyond.
I don't mean to sound harsh, but it's difficult to continue to hear unjustified conclusions against using the RDF as a guide in our work equal in stature to the Extensible Markup Language itself.
Both are formal W3C Technical Recommendations, and both have been so for almost four (4) years now.
The RDF defines a sensible architecture equally applicable to commercial invoices as it is to court records and court documents.
RDF is a STANDARD from the principal standards body we cite in our charter, so we should be reflexively desirous to adopt it.
LegalXML should also encourage the federal government to adopt RDF as a standard, immediately, to truly improve data-sharing among its branches.
RDF is a STANDARD that should be adopted by all regulatory agencies, to improve the quality of information solicited from industry, to minimize the cost and maximize the effectiveness of the envisioned "data mining" across public and private datasets that undergirds part of our present war strategy -- there is no reasonable downside to standards adoption; there is no justification not to adopt RDF, now. Simply standardizing on XML is hardly sufficient -- a babble of grammatically dissimilar dialects clearly results.
There is also no published alternative architecture that I'm aware of that compreensively addresses both instance documents and their metadata.
XML Schema only discusses metadata, and is almost silent on instance document structure.
RELAX-NG is a hack on XML Schema, and even seriously proposes a nonXML encoding scheme.
(Both of which are handicapped by being only incidentally object-oriented).
Understandably, the single specification that LegalXML has built to date is "cautious" in its formulation, given its timing relative to our understanding RDF, and given that WSDL is not yet a formal W3C standard.
However, nothing prevents our specifications from now building upon an undeniably important standard established by the W3C

--
RDF -- one that is a documented part of a decent architectural vision, that is supported by open-source and commercial tools, that is written about in the popular technical press (books, magazines), one that is technically pretty darn good.
Perhaps if future specifications from LegalXML were guided by their own architectural vision in some way, I'd be more encouraged.
But none is published or mentioned anywhere at any time.
This is why I call the DTDs created to date haphazard.
This is why I think the conversation aimless and nonspecific.
It is one that has yet to draw any simple distinction between the requirements of exchanging court records as opposed to court documents, as they do have entirely different stakeholders interests to satisfy, and different technical approaches to be taken.
I do know that you are one of the strongest members of this organization, that you come to this table as a smart attorney with a hobby horse for XML markup.
Thankfully you're the (ideal) leader of the eNotary TC.
Your expert participation and good will are essential throughout this process of developing work products used principally by technologists.
So, I hope you agree that at some point the process of designing the markup itself is best led by the technologists who'll eventually have to eat this dog food.
It shouldn't be a goal here to "simplify" extant standards so that non-technologists could presumably perform a job for which they are not trained, which they're unlikely to do to any degree in any event.
Likewise, I am not trained in law, but am here to join forces with functional experts like yourself to achieve the goals that we share, deferring to you in matters in which I have just a common man's understanding.
We are creating a technical product of central importance to technologists, and I must stand opposed to seeing a quality product consistently deferred for no given reason beyond a concern about political landmines.
So, we should adopt RDF now, not in V2.0.
Regards, John Hypergrove Engineering Port Townsend, Washington