[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: A legal: namespace
Folks, Modular XHTML requires that we designate a "default" prefix for our elements. I vote for "legal:" to be used in our standards documents. Below I discuss four elements: <legal:instrument>, <legal:signature>, <legal:layout>, and <legal:attachment> for this namespace. Jason says: "We wouldn't be an XHTML (1.0) host Language either, since http://www.w3.org/TR/xhtml-modularization/conformance.html#s_conform_document_ty pe says we have to keep <kbd>, <l>, <sample>, <var> etc to be that." What exactly is wrong with using these elements? <xsl:value-of> certainly can overlook them. I am very uncomfortable telling people what they cannot do without a compelling reason; I'd rather support what they are doing. A subjective judgement of "what is burdensome to attorneys" isn't compelling to me at all. I mention the <hx> elements because they imply the coder is not encapsulating their sectional content, that they are not creating grammatical paragraphs. I think grammatical paragraps ARE a key requirement for linking and retrieval mechanisms. It seems that the "Simple Paragraph" you propose is implemented well enough in XHTML 1.0, while please note that its lack of a GPara is what is being "fixed" in 2.0 for a good reason: it encapsulates content that can be further analyzed by specialized software. Jason: Will one be able to say "i want to use a defined term here", and if so, get a popup list of terms defined in the document? Similarly for cross references?" Sure you can. While I flinch at using a <dfn> element because there's no certainty that it reliably contains the definition of a term, I think the most useful approach would be to use <meta> elements to identify "keywords" defined by the document. Within the document, <dt> elements indicate their use. Anyway, I think a list of <meta> keyword elements could be displayed to the user, and is an approach appropriate to the <meta> element. For cross-references, the <a> element is traditionally used for citations. It can cite a section, table, navigation list, image, or external content. Sounds quite adequate to me as a basis for lists of proper choices. But I don't know yet how the <cite> element fits in -- it should be adopted in some way since it forcefully suggests our "niche" of legal citations. Jason: "So in any event, we're unlikely to have "strictly conforming" XHTML 2.0 documents (sec 3.1.1) - since to be that, it looks like you can't add your own elements." I don't see why a "strictly conforming" XHTML 2.0 datastreams can't be designated a conforming legal instrument ONLY AS LONG AS they contained a pointer to RDF metadata designed by this committee. But I agree there's real value in an XHTML module or two that yields (a) a container for <section> elements. I think a <legal:instrument> is necessary. This contains a <legal:attachment> element that clearly binds legal backmatter to the primary instrument; a <legal:attachment> can contain its own <legal:instrument> of course. (b) an element for a signature as rendered by a User Agent. Since a legal instrument requires the parties' signature, so a <legal:signature> element is required content of a <legal:instrument> element. It needs to accommodate image representation as well as a text representation of a signature. Does it need to be only inline content, or is there really a necessity to represent the dates, typed names, etc, common to a signature block? All the meta information that could be there would equally be located in a digital signature as applied by an notary to the contract. Why need to duplicate all that information? An exchanging applicaton would rely on that data source, not the document. Sure, it may make notary application simpler, but really, thesethings are going to be driven more by workflow databases where all that info is already stored, than it will be by extracting information from the XML. (c) an element for a layout area. It seems clear that a <section> element should only be used to layout content that is to appear in a "running" XSL-FO. We need to distinguish between the areas to be layed out. A <legal:LayoutArea> is needed, to which <rdf:type> elements can be added to represent signature areas, running headers, page footers, and so on. The objective is a set of elements for XSL stylesheets that convert from the XHTML into reasonable XSL-FO (and hence PDF) representations of the document. I considered elements for tables of attachments, citations, and inclusions. but I think these can be handled by adding an <rdf:type> element to the XHTML 2.0 navigation list element <nl>. Without an <rdf:type>, the <nl> is still to be taken as a representation for (an incomplete) table of sectional contents, that is, of <section> elements. -----Original Message----- From: Jason Harrop [mailto:jharrop@speedlegal.com] Sent: Friday, November 21, 2003 9:15 PM To: Legalxml-Econtracts Subject: Re: FW: [legalxml-econtracts] Re: XHTML 2.0 I wrote: > A. When will it be ready? How final is it? Maybe Dan or Dave can get some visibility on this from the non-public W3C mailing lists. This goes to your claim 3. According to http://www.w3.org/MarkUp/xhtml-roadmap/ XHTML 2.0 is intended to be a Candidate Rec in Jan 2004 and a Proposed Rec in Oct 2004, but then again, that roadmap says "Last Call" in Oct 2003... John McClure wrote: > B. What does the subset you are proposing actually look like? What elements > are in it? ie what is the concrete proposal, expressed as a schema (W3c, relax > or dtd) > > I favor deprecating, not removing, elements from whatever schema > the W3C issues for XHTML 2.0. It seems to me that the W3C committee > is (a) doing the right things so far and (b) open to change. It's a good > sign to me that they've create a grammatical paragraph and a recursive > container element, meeting two key requirements. Grammatical para may not be a key requirement - its yet to be seen - though it is a possible solution pattern for us. Re the recursive container element, yes, that's good, though they still have separate list structure - lists inside p, and section siblings - with all the issues that raises. > It even seems they're > thinking of dropping the <hx> elements altogether, so I am hopeful that > no deprecation needs to happen at all. So when their XML editor asks "what can go here", contract authors will see a long list of elements which aren't relevant to contract authoring? eg "code" for computer code, <kbd>, <l>, <sample>, <var> etc?? Will one be able to say "i want to use a defined term here", and if so, get a popup list of terms defined in the document? Similarly for cross references? To enable things such as this, we may need to add our own elements in eg the inline module (for this definition example, the proposed "dfn" element gives us the definition, but we need something else to "use" (ie IDREF) a definition) > > C. How does it compare to our other candidate for a range of authoring and > other tasks, which we can list and then answer. ie we need to be comfortable > that your claim one - that it is adequate - is fair. > > There is every reason to believe that current X/HTML editing tools, > both free and proprietary, will be updated for 2.0. > Your response doesn't address the point i was trying to make.. And in any event, those tools are unlikely to be what someone who authors contracts everyday for a living will be using. Current X/HTML editing tools are used by web authors, but not so much by contract authors/managers. They are unlikely to use them as such. To be compelling, the tool must add value, addressing issues such as: - How will re-use be facilitated? - How will they add definitions and use them? etc etc. They might use Word 2003, or some other tool customised for editing contracts. And for these tools, the question is how easy will they be to use, and what _characteristics does the underlying grammar have to have_ to make it easy to use? The authors won't care whether its some XHTML variant, or our clause model. But they will care about whether they can do their job easily. It is clear they could not do their job (adequately) using "strictly conforming" XHTML 2.0 in an off the shelf (non-customised) XHTML editing tool. Whether they could do it using a customised X/HTML language would depend on the extent of the customisations to the language, and probably the tool as well. thanks Jason ps more technical stuff below. Turnning back to the roadmap (and more technical stuff) ... So far as "Modularization 2.0", all entries are "TBD", but that's understandable, since the current draft is already done as a series of modules. The current draft says at sec 1.2: "XHTML 2 is a member of the XHTML Family of markup languages. It is an XHTML Host Language as defined in XHTML Modularization. As such, it is made up of a set of XHTML Modules that together describe the elements and attributes of the language, and their content model. .. Over time, it is possible that the modules defined in this specification will migrate into the XHTML Modularization specification." More now on B... So in any event, we're unlikely to have "strictly conforming" XHTML 2.0 documents (sec 3.1.1) - since to be that, it looks like you can't add your own elements. We wouldn't be an XHTML (1.0) host Language either, since http://www.w3.org/TR/xhtml-modularization/conformance.html#s_conform_document_ty pe says we have to keep <kbd>, <l>, <sample>, <var> etc to be that. To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/legalxml-econtracts/members/leave_w orkgroup.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]