RE: [legalxml-econtracts] The case for Authoring

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

Very interesting, thank you Rolly. They all sound pretty primitive to me,
particularly if there is no pseudonym capability for element names, attribute
names, or attribute values that are displayed in the windows or menus you
described..... in fact it will be very interesting to find out how they evolve
to handle XML namespaces, that is, how they will handle the complete XML Schema
specification, not just part of it, in a naive-user-friendly manner. I cannot
believe that psuedonym capabilities won't be introduced at that time.

Anyway let me see if I understand this correctly.

1. You work 95% of the time in markup mode -- let's call this "codes".
2. Jason says that attorneys don't know/don't want to see the "codes". I agree.
3. Therefore these tools don't seem typical to the "user" Jason talks about.

So my question still remains: who is going to read and use our spec, an attorney
who hates "codes", or a programmer fielding an application for the attorney to
use? Who is going to produce the XML markup -- the attorney who hates "codes",
or the programmer, within the application software she's writing?

My argument remains -- while authoring is an important and chartered scope for
us, I think the percentage of the ultimate attorney user base that will be
entering markup directly is VERY LOW. Which means that the benefit of the doubt
during design decisions should tilt towards the needs of programmers, not those
of the atypical end-user attorney who loves entering "codes" in a raw, seemingly
unproductive, environment.

Thanks,
John

>-----Original Message-----
>From: Chambers, Rolly [mailto:rlchambers@smithcurrie.com]
>Sent: Saturday, July 24, 2004 4:29 PM
>To: John McClure; Jason Harrop; Legalxml-Econtracts
>Subject: RE: [legalxml-econtracts] The case for Authoring
>
>
>
>See inline comments below.
>
>-----Original Message-----
>From:	John McClure [mailto:jmcclure@hypergrove.com]
>Sent:	Sat 7/24/2004 12:08 PM
>To:	Jason Harrop; Legalxml-Econtracts
>Cc:
>Subject:	RE: [legalxml-econtracts] The case for Authoring
>Jason said:
>>But - and this is a critical point - someone has to author the template
>>contracts and the clauses which appear in the clause library you refer to.
>>In my experience, these people are attorneys or other people who do
>>not have an IT background, and know nothing about HTML or XHTML
>>(unless they have web publishing as a hobby).
>>
>>Assuming an eContracts XML environment, those people will probably use
>>XML tools to create the contracts and clauses.
>
>
>Jason,
>Again I patiently request, please describe these "XML tools" in some detail.
>This baseline information will inform and guide us to a better standard.
>
>[RLC - I've worked fairly regularly with the following XML editing
>tools to create XML documents:
>
> - Turbo XML 2.4.1;
> - Morphon 3.1.2; and
> - epcEdit 1.2.
>
>I've experimented with trial versions of many other XML editors
>(including XMLmind, Serna, <oXygen>, and XML Spy). I'm currently
>checking out Butterfly XML.
>
>I think I've got a reasonable feel for what "XML tools" means at least
>in the context of XML document authoring and editing.]
>
>Here's some specific questions ....
>
>1. Do they require the user to interact with the markup directly? When?
>
>[RLC - The three I've regularly used don't require an author to
>interact with the xml markup at all, but they permit an author to work
>with xml source markup -- the pointy tag stuff -- if you want to.
>Morphon and epcEdit display the xml element tags (if you want to see
>them) not only in "source view," but also in a view that reminds me of
>the old Word Perfect reveal codes. These two applications also let you
>create stylesheets (Morphon uses CSS2) so you can view the XML
>document without any tags and as styled if you choose. epcEdit does
>the same thing but uses a different styling mechanism than CSS.
>
>Turbo XML uses what is basically a table - element names appear in a
>column on the left and text content appears in a column on the right.
>
>I rarely work in "source view" with any of these tools. I almost
>always use the tag view. Working in display view without any view of
>the tags isn't easy  during authoring because you can't tell exactly
>what point you're at in the xml document and thus, you can't tell what
>elements are available for insertion.]
>
>2. Do they require the user to select elements? to select attributes? How?
>
>[RLC - Morphon and Turbo XML have the capability to use dtds or xml
>schema to give authors a list of valid element names from which to
>select an element of insertion depending on where you are in the
>document. Morphon displays the valid available elements in a
>sub-window and Turbo XML displays them in a list. epcEdit uses only
>dtds for the same purpose and displays the element names in either a
>sub-window like Morphon or alternatively in a drop down list. For a
>new document, they will display the required elements at the outset,
>then leave it to the author to begin adding the optional ones.
>
>To select attributes, Morphon and epcEdit use separate frames/windows
>adjacent to the main editing window. Morphon also uses a pop up window
>as an alternative for selecting attributes. Turbo XML sticks with the
>table type interface -- attributes and elements appear as rows, but
>have different icons in front of the element or attribute name
>(attributes are a circle and elements are a diamond).
>
>You simply click on the name of the element or attribute you want to
>insert using any of these applications and the element or attribute is
>added to the xml document. With attributes, you also have to enter the
>value of the attribute. If there are enumerated values in the dtd or
>xml schema, these applications also give you a list of the enumerated
>values to pick from by clicking on them.
>
>You can author or edit a well-formed xml document with any of the xml
>tools I've tried, but not all of them have validation capability like
>Morphon, Turbo XML, and epcEdit.]
>
>3. Do they require the user to provide values for attributes? for IDs and
>IDREFs?
>
>[If the dtd or xml schema requires an attribute but you omit it, then
>these tools indicate that your xml document is not valid. They do this
>either with an error message indicating what the problem is or by a
>visual cue (the invalid element is highlighted or colored red).
>
>Unless the dtd or xml schema requires an id or idref attribute,
>Morphon, epcEdit, and Turbo XML do not require it. If an ID or IDREF
>attribute is required, then they require you to enter a proper value
>or else indicate the xml document is not valid. They do not
>automatically generate values for id or idref attribute -- the author
>has to enter them.]
>
>Please answer these simple questions, most particularly #1. I'm interested
>ultimately in answering the basic question -- who really needs to read and
>understand our specification -- the end user attorneys, or software developers?
>Your answers I hope will bring us closer to a resolution of this sticky issue
>before us.
>
>Thank you in advance,
>John
>
>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.





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.