OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

legalxml-econtracts message

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


Subject: Official XML Records


Title: Re: [legalxml-econtracts] The CSS issue (was .. Req #106)

It's interesting that the CD TC is grappling with similar issues of what is the official record. May I contribute to that discussion by noting that a PDF image SEEMS immutable ONLY BECAUSE the viewer for it comes from just one, world-wide source -- Adobe. Adobe now has a viewer for SVG images available (http://www.adobe.com/support/downloads/product.jsp?product=46&platform=Windows), so my assertion is that presentation of a Court Document using SVG can be considered by courts as immutable as PDF and, of course, it is XML, so it can be annotated with a "names" attribute referencing markup names defined by, say, any LegalXML TC. Adobe I strongly suspect is also doing an XSL-FO viewer, whose W3C recommedation followed the SVG recommendation. Remember, Adobe was a primary author of SVG, the XML equivalent of their PDFprotocol .... so I suspect, based on what is happening in the open-source arena, that their XSL-FO viewer will transform the XSL-FO to SVG internally, and then use the SVG viewer they're distributing.....
 
Anyway, I suggest that my "names" solution is appropriate to the needs at hand -- immutable and exchangeable presentations. I am encouraged that it looks like people are understanding the same problems I've often not expressed very well. I expect many will arrive at the same solution that I have -- annotating the presentation datastreams with semantic names defined by functional workgroups is a reasonable division of labor. Its effect is to evolve the principle function of TCs like eContracts and Court Documents FROM developing an XML namespace that is relatively unlikely to be globally adopted TO defining the logical model for the data found in the presentation documents, a much better use of domain experts' time in my opinion, with a much greater chance of long-term relevance. At the same time, I have proposed specific XML elements for the eContracts TC primarily in the belief that (a) the group is yet unprepared to make the "great leap" of using XML namespaces already defined by the W3C (XHTML, SVG, and XSL-FO) as the only protocols acceptable for exchange of "an official record" and (b) since I have stylesheets that convert from names to elements, and from elements to names, then for me this is not wasted work.
 
I'd like to note that citations to material within court documents (and within contracts) is absolutely essential to the public interest. The obvious mechanism for citations is the "hyperlink". One would expect, when selecting a hyperlinked citation, to go directly to the artlicle, section, or paragraph cited, that is, its presentation within the context of its surrounding document. (I think merely linking to its document, and not to the cited material itself, is quite inadequate). However, one can only hyperlink directly to a presentation element in order to see its formatted context. If the presentation element is one that is generated "on-the-fly" by an XSL-T stylesheet, then there is no physical element to which a hyperlink can be directed, and thus one cannot hyperlink to it..... Accordingly, I believe it is essential to the public interest that the official record be marked up in an XML suitable for presentation, so that people can hyperlink to citations in their context.
 
Further, I assert it is essential that markup regarding the semantic content of Court Documents be represented as annotations on the XML elements themselves, not as separate, stand-aside markup because,technically, "stand-aside" markup would be relatively harder to create or modify than the embedded "names" notation, since it would rely so completely on the somewhat complex machinery that XPATH provides to reference substrings within content of an element. One possible (related) solution I imagine is to package XSL-T output in a signed package of resources, however I see this as a band-aid, because the presentation still is divorced from, if it is correlated at all with, the underlying semantice markup that LegalXML groups are defining -- hence, while the presentation artifact becomes the official record, to which one can hyperlink, we lose all the benefit of searching for specific semantic content within an official record. I urge us, instead, towards a simple solution: annotate the official record with markup names, and be done with it.
 
So, I think the tools, practices, and infrastructure do, or will soon, exist such that all "official records" can be represented as XML documents. That said, I can understand why courts suggest accepting PDF in the short-run, while believing this is not a useful or relevant policy for the legal profession to implement in the medium-term.
 
John McClure
 
-----Original Message-----
From: Chambers, Rolly [mailto:rlchambers@smithcurrie.com]
Sent: Sunday, April 20, 2003 3:02 PM
To: legalxml-econtracts@lists.oasis-open.org
Subject: RE: [legalxml-econtracts] The CSS issue (was .. Req #106)

As one of the authors of the Court Document spec, maybe I can chip in something here. It is correct that the Court Document XML spec is not particularly concerned about how the XML representation is turned into a presentation image. However, an issue has surfaced with the XML Court Document spec that is very similar to the one here - whether the XML representation of the court document should serve as the "official" document of record or whether some presentation image should.
 
The problem with using the XML representation as the official document is there are many different ways to present it and it is difficult (if not impossible) to assure that the presentation used and envisioned by the sender/filer will also be the same presentation received and used by the recipient.  There are differences in browsers and, I am told, in XML-to-PDF applications that makes this a problem whether a CSS, XSL-T, or XSL-FO stylesheet is included with the court document as a set of "presentation instructions." The idea that the presentation image a lawyer sends to a court will turn out not to be the same presentation image that the court views is anathema to most lawyers.
 
For that reason, the Court Filing TC is now envisioning that the official "court document" filed (i.e. exchanged) with a court will be a .pdf image rather than (or perhaps in addition to) the "unofficial" XML representation.
 
While Jason's description of the approach taken by the XML Court Document spec is correct, I believe that approach does not necessarily solve the "what gets exchanged" issue that we now are focusing on in the context of contract documents. That said, I also believe there is a place and a need for a standard XML representation of contracts as long as the possible limitations are kept in mind.
 
Rolly Chambers
-----Original Message-----
From: Jason Harrop
Sent: Sun 4/20/2003 8:57 AM
To: legalxml-econtracts@lists.oasis-open.org
Cc:
Subject: Re: [legalxml-econtracts] The CSS issue (was .. Req #106)

. . .

I think the proper role of our standard is to represent the contract in
XML, in the same way the Court Document DTD represents a court document.
 See
http://www.oasis-open.org/committees/legalxml-courtfiling/documents/court_document/index.shtml

The Court Document people had no need to be too concerned about how the
document gets from the XML representation to some presentation image,
and neither should we.

. . ..

winmail.dat



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