RE: [xml-dev] Granularity

["Cox, Bruce" <Bruce.Cox@USPTO.GOV>]

When developing our Reference Document Management Service, we asked the editors.  They wanted to be able to edit in sub-sub-sections, so that more than one editor could work in the same chapter at the same time.  The CMS doesn't support XInclude, so rather than hack a method of reassembly, we made the storage unit, and therefore, the smallest editing unit, the chapter.  When the content is prepared for search, we chop the chapter at every hierarchical level so the results list is rich in detail, even if a bit redundant.  This is working OK at the moment.

In the patent examination process, however, there are other considerations.  An office action (official communication from an examiner to an applicant) is constructed from data derived from the applicant's particulars, free-text written by the examiner, and highly formalized boiler plate known as "form paragraphs" written by lawyers for lawyers.

More generally, if the business vocabulary has a word for it, it's a candidate for an element, a content model, or a document.  If a business process calls it out, it's likely to be reused.  When we ask users (the usual practice), we're often surprised that, in one context, for example, distinguishing first-middle-last is wasted effort, but in others, it's critical.

In developing WIPO Standard ST.96, a replacement for WIPO Standard ST.36, our goal is to maintain the same level of granularity for elements and attributes they have in common to facilitate bi-directional conversions.  As a rule, though, the general trend in ST.96 is to be more granular with fewer complex content models, and more modular schemas overall.  It isn't easy finding an agreeable level of granularity among thirty or so international agencies without becoming so abstract as to be useless for actual business transactions.  But we have fun trying.

Bruce B Cox
USPTO/OCIO/AED/SAED


-----Original Message-----
From: Dan Vint [mailto:dvint@dvint.com] 
Sent: 2012 January 5, Thursday 21:48
To: Len Bullard; xml-dev@lists.xml.org
Subject: Re: [xml-dev] Granularity

Depends, are you writing traditional manuals or are you using the new modular writing paradigm? Do you have a CMS or are you using the file system. Modular writing with DITA and S1000D seems to set the level of granularity at the topic and provides a mechanism and philosophy for managing the content and reuse.

Traditional manuals are more problematic and typically a chapter is about the best I have seen managed. Both for the number of files as well as having all the right content available to make it reasonable for a writer to make the required changes. IPB works well at the figure level, same with work cards at the task level. Trouble begins in trying to name the parts and then manage them.

The OO based CMs systems (Astoria) always touted the ability to randomly pick and choose where the author could work, while the relational based systems always required you to set the level of granularity and you paid a big price if you wanted to change it later.

..dan

At 04:14 PM 1/5/2012, Len Bullard wrote:
>When building XML systems, how do you choose the best granularity for 
>storing and retrieving fragments?
>
>Machine to machine
>
>Human to machine
>
>Human to human
>
>Part of the art is interpreting what branch and leaf combinations best 
>give a role/user the most copacetic view.  How do you choose?  Does the 
>user choose?
>
>The proportion of XML consumed and emitted by machines or humans is 
>not interesting,IME.   The cost and type of the value-add of the 
>humans consuming and emitting XML is.  In documents, this is 
>obvious.   Granularity.
>
>len

---------------------------------------------------------------------------
Danny Vint

Panoramic Photography
http://www.dvint.com

voice: 619-938-3610