Re: [legalxml-econtracts] The case for Authoring

[Jason Harrop <jharrop@speedlegal.com>]

John,

I'm afraid your reasoning doesn't make much sense to me.

You ought to download and try a selection of them, so that you can make 
insightful contributions about authoring.

If having tried them, you still think they are pretty primitive, well, 
don't expect them to change much soon.

Some of the tools (Epic, Framemaker, XMetaL) are quite mature, having 
been born in the SGML era.  Others are creatures of the XML revolution.

The core functionality tends to be pretty similar. There are a thousand 
flowers blooming at the moment (most pretty similar), and someone might 
yet devise a revolutionary approach which takes hold ...

Some of the tools are programmable (eg XMetaL), so programmers can 
customise what the author sees to a greater or lesser extent.

Nevertheless, we should be aiming to make our grammar usable out of the 
box, without having to customise the tools to any great extent.  If 
customisation yields additional benefits, then people will do it.  But 
we shouldn't make it necessary, and certainly not for the basics.  We 
want people to be able to try the TC's work, without having to go to 
great lengths to make sense of it.  Our work needs to be accessible.

Its probably also worth saying that some customers will select a 
commercial off the shelf tool; while others will use a tool 
custom-developed by an eContracts vendor.

 > 2. Jason says that attorneys don't know/don't want to see the "codes".

Did i say that?

There are times when you need to see the XML tags, such as:

- when pasting text (including markup), to a location which is at the 
edge of another tag.  You need to see whether you are inserting as the 
last child, the following sibling of the parent, the first child of that 
sibling etc

- when moving chunks of XML around.  Sometimes you want to do this is a 
tree view of the structure, and maybe sometimes in a text view (a la XML 
Spy) with tags on.

- when inserting new elements ("what goes here?").

None of this means that you can't work in a WYSIWYG view of the 
document, which is what I think attorneys expect.  That is, the author 
can expect to see their text with styles applied; but for the reasons 
given above, the tags never go away entirely.

cheers,

Jason




John McClure wrote:
> 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.
> 
> !DSPAM:4104c100162331199620156!
> 
> 
> 

-- 

Jason Harrop
CTO, SPEEDLEGAL
jharrop@speedlegal.com

Melbourne
www.speedlegal.com

SmartPrecedent(R) software
The most intelligent way to create documents