(h) Schema languages

["John McClure" <jmcclure@hypergrove.com>]

Jason said:

>If you'd like to copy/paste your sections (g) and (h) from your "long" memo 
>(or something based on them) to the list, i will respond.

Section attached, as you requested.
John

(h) Schema languages

	Now I will address the issue of document validation because, for schema-
	driven applications, it determines what elements are displayed that may
	then be selected to be entered at any point in an element structure by the
	application. This is a concern primarily of those directly perfomring text
	entry to a schema-based application, because most other applications
	that might be used by attorneys are an application "system" that little
	doubt has a stylesheet (one consuming, i.e., reading, our XML schema)
	to validate the stream prior to storage of the document in archives. [I
	don't understand why a Schematron stylesheet' is any better than an
	XSLT stylesheet for this, and could argue that it's a whole lot worse.]

	So Jason's  concern is that an author could create a stream with more
	than one footer, for instance. That is, if our standard identifies such an
	element as a footer element by using the @class attribute, then DTD
	validation facilities cannot be used to ensure that there is only one
	footer for a <div>, for instance. XML Schema validation facilities can't
	be used either, because XMLS' content models also cannot be qualified
	by given attribute values had by the element being validated.  [There
	is one option though that uses XML Schema's @xsi:type attribute, not
	the @class attribute.]

	It's said that one alternative is to create a RELAX-NG schema for the
	standardized elements, which does allow such qualification for its
	content models. Certainly I think that any RELAX-NG schema should
	be co-publiched with standard DTD and XML Schema schemas, while
	shortcomings of each are discussed within the specification.

	That said, their reasoning becomes this: because RELAX-NG (nor
	xsi-complete XML Schema) tools aren't widely implemented, it is thus
	necessary that we establish element names, not element attributes,
	to represent the concepts called for in our requirements document.
	Several problems with this though: (a) assumes a particular set of
	tools that I don't believe are typically being used to enter language
	of the contract (b) assumes a particular level of capability of those
	tools that I don't believe will persist very long (c) assumes that the
	tools will never provide the capability to call a stylesheet to edit text
	input dynamically, or to create the "lists" of options that a user has
	at a particular point in the document's markup. In short, it's truly
	poor idea to assume that APPLICATIONS will not change over the
	next few years to accommodate whatever the standard happens
	to be. In other words, it often sounds as if the discussion of what
	is possible -- what is desirable technically -- is beholden to how
	certain applications are currently designed to operate.

	Of final note on this topic, is the pressing issue of getting the W3C
	to establish a conformance level that represents a 'middle ground'
	between its now two levels of XHTML 1.1 conformance, one that
	reflects that the operational elements we've included from XHTML
	2.0 are but a constrained subset of those defined in their modules
	(e.g., no PCTEXT in a <section> element). They are developing I
	understand an XHTML 2.0 schema in all 3 of the popular dialects,
	each described with relevant caveats. Clearly all this relates to our
	ability to provide the schema-driven markup editors a schema that
	reflects our standard.