[Cmacc] technical design decisions

[Adrian Gropper]

There are privacy and confidentiality issues to doing stuff on the server
that could be done on the client.

Adrian

On Thursday, December 18, 2014, Christopher Clark <ludachrispeed at gmail.com>
wrote:

> Some questions on the CommonAccord technical design:
>
> *API*
>
> Would you all consider moving to an API that returns only the document
> texts, as opposed to HTML documents with the legal text in it somewhere?
> That would allow other online services to consume the CommonAccord API.
>
> *On Moving to Javascript*
>
> Are there any specific benefits you are looking for by moving the parsing
> client-side? I actually can't think of any; you wouldn't be able to get rid
> of the server, because the server would still have to store all the
> templates. And by moving everything client-side, you lose the possibilities
> of:
>
>    - providing an API that other online services could use
>    - doing any cool post-processing on the document (like creating an
>    ODF, DOC, PDF, applying formatting, etc)
>
> Also, if parsing were client-side, the parsing code would likely mingle
> with the UI code, which would make it harder to create new UIs for
> displaying/rendering the legal texts. Since CommonAccord is mostly about
> legal content and not about any specific UI, there's a good argument for
> focusing on how to offer the content in the most agnostic way without tying
> it to a specific UI which you have created.
>
> Also, say two people want the same contract. Shouldn't it be created once
> on the server and then sent to both people? If documents can only be
> created in the browser, the likely use case would be that one person
> creates the contract in his/her browser and then personally sends the
> document to relevant parties.
>
> *On LegalXML (or really any XML format)*
> Using an XML format as the output (like LegalXML) might be something to
> discuss:
>
>    - XML documents can be translated into other XML formats using XSLT.
>    Since the Open Document Format (what OpenOffice and LibreOffice use) is an
>    XML format, I suppose you could potentially convert LegalXML (or whatever)
>    into ODF. (On a side note, Google Docs just added support for opening ODF
>    documents).
>    - Using a well-defined output format lets other people with bright
>    ideas build off your work more easily
>
>

-- 
Adrian Gropper MD
Ensure Health Information Privacy. Support Patient Privacy Rights.
*http://patientprivacyrights.org/donate-2/*
<http://patientprivacyrights.org/donate-2/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.commonaccord.org/archive/cmacc/attachments/20141218/e12ef0ee/attachment.html>