[dev] Docs Module (was: Horde Summary Layout options, in HEAD maybe?)

[Eric Rostetter]

Quoting Ryan Gallagher <ryan@studiesabroad.com>:

> > I'd rather see us use an existing XML format than create new ones, if
> > possible.
> 
> This intrigued me for several reasons. For end user and technical documents,
> obviously there are  many pre-existing DTDs or even Schemas about.  But I
> wasn't
> just envisioning a "documentation" system, but a more versitle "document"
> system.  Document examples might include:
> 
>  - Expense Reports
>  - Form Letters
>  - Meeting Notes
>  - Process/End User Documentation (like you were envisioning)
>  - FAQs (like you indicated)
>  - Standardized 'Purposal' type documents
>  - Office Documents (such as Vacation Request Forms, etc etc)
>  - For where I work, things like Course Descriptions, Course Syllabi,
> Itineraries etc might be included in this list.
>  - etc...

I think the only difference between this and existing document formats is
perhaps forms.  So if we found one that did forms, we should be okay.

> Essentially a method and system for defining any commonly used document type
> in
> a office/community enviroment. Hence my desire to have the available document
> types be dynamic and 'pluggable'.

Or just very large and complete. 

> This is also where the "web-editable" feature
> i'd love to see comes into play.  For the documents vary in nature and the
> audience of authors would likely range equally far and wide.  Hence the

Yes, I agree that making it web-editable would be best.  But this could be
a "stage 2" thing if you wanted.  Start with documents, then make an edit
frontend to it.

> no reason that CVS couldn't remain the backend (along with other options).

Yes.  The only thing CVS really buys here is 1) existing technology and
2) versioning.  Other than that, it isn't important.
 
> But obviously setting it up for read-only web access is a much easier problem
> to
> tackle initially.

> > I think it would be XML nature, not web-centric nature.  And CVS would give
> > you versioning.  Make would be simple if you have an XSLT engine (like that
> > php provides via sablotron).  I think we might have to provide already
> > converted versions for those who don't have access to, or simply don't know
> > anything about, and XSLT engine.
> 
> I think we mostly agree here, the web-editable aspect was the only issue that
> was in serious question.  That and the option for varying document types.

I think the web-editing part is good, but should be a add-on front-end rather
than a core design issue.  In other words, define what the data looks like,
how to translate it, etc.  Implement that.  Then worry about editing frontends.

-- 
Eric Rostetter
The Department of Physics
The University of Texas at Austin

"Can you hear me now? ... Good!"
"Can you hear me now? ... Good!"