a 'doc' field value -- ideas?

Will Partain <[email protected]> Fri, 24 Aug 2001 21:23:45 +0100
Newsgroups gmane.comp.sysutils.ark.devel
Message-ID <[email protected]>
Context: an ARK world is made up of "things" (hosts,
packages, vendors, users, ... what-nots) [each represented
by an XML file], each simply being a collection of "fields"
(ip-addresses, fstab, ... for hosts; surname,
favorite-ice-cream, ... for users; and so on) [each
represented by an element in XML].  Though what fields a
thing has is almost entirely up to you, what comprises a
field is *the same* across the board (params, constraints,
and ... a value).  [It's crazy, but it works :-)]

At present, a field can have one of four kinds of value: a
string (very common), a table, a list, or a "code" (a
fragment of scripting that can be run, printed, pawed over,
...).

I'm proposing a *fifth* kind of a value, a "doc", being "a
fragment of documentation".  A <doc> would be a splodge of
text, plus a bunch of properties, possibly including
"format" (plain text, HTML, XML, texinfo, ???), "language"
(as in English, French, etc.), "view" (user, sysadmin), and
who knows quite what.  So you might have:

  <description><doc view="user" lang="en">
  This thing slices and dices.
  </doc></description>

  <description><doc view="user" lang="en" format="bad-html">
  This thing <blink>slices and dices</blink>.
  </doc></description>

  <description><doc view="sysadmin" lang="fr">
  Je ne suis pas dan la salle a manger.
  </doc></description>

My initial thought about the (Python) programming API,
i.e. what you get when you type

   descr = thing.description()

is that 'descr' will return a list of pairs, the pair being
the text and a hash of the properties.  Thus,

   print `descr`

would give (pardon my python)

   [ ('This thing slices and dices'
     , {'view': 'user', 'lang': 'en'})
   , ('This thing <blinks> and ...'
     , {'view': 'user', 'lang': 'en', 'format': 'bad-html'})
   , ('Je ne suis...'
     , {'view': 'sysadmin', 'lang': 'fr'})
   ]

It's up to the caller to know what to do with this; we would
presumably supply utility routines for common grokking
patterns.

Anyone with any thoughts?  (I am planning that the next
mini-iteration of the webware stuff will use this)

Will