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: 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]