[Cmacc] technical design decisions

[Jim Hazard]

Great to see this discussion. 

Local Rendering:

I think it is inevitable and optimal that there be client-side rendering.  This is necessary for a real peer-to-peer system.  It is consistent with the way web pages are currently made (CSS, images, etc. are fetched and assembled locally).  That doesn’t mean that it is the first thing we need to work on (I’m agnostic) and doesn’t exclude rendering on the server side.  There will be lots of those use cases.  There are likely to be mixed cases, too, where the server sends, say, a rendered form and the client blends in the deal points. 

Chris, tying in with another part of your thoughts - local rendering also allows use of a local database or local files.  For some time, I had a system that used all three.  I could edit a form in OpenOffice, pull elements from a wiki and use a database of terms.


XML and other Formats:

Applied to documents:

It would be great to have clients;APIs;What-have-you for OpenOffice, Word, etc.  In both directions, to allow them to pull content from Cmacc and put content in.  My sense is that this kind of use would be transitional.  The point of CommonAccord in the legal domain is, finally, to get rid of documents and have only data.  We render documents because that is how the world now operates.  In the legal domain, rendering is to achieve backwards compatibility. 

In other fields, where one really wants a page of stuff to read, rendering is the goal.  But my guess is that most of that is or will be in the browser.

The semantic part of LegalXML etc. seems less useful to me, though there is likely to be valuable learning and ecosystems.  The easiest way to tag and reuse text is to keep it in source format as key/values.  


Applied to source:

Our current format for key/values is the simplest possible, but there are good reasons to store or ship it in other formats.  JSON is an obvious choice.  XML is fine, too.  My guess is that we will find that we want to improve, especially in transport. 



   


On Dec 18, 2014, at 6:48 PM, Adrian Gropper <agropper at healthurl.com> wrote:

> 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/  
> 
> 
> _______________________________________________
> Cmacc mailing list
> Cmacc at lists.commonaccord.org
> http://lists.commonaccord.org/listinfo/cmacc

Jim Hazard
@hazardj
650.454.5007

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.commonaccord.org/archive/cmacc/attachments/20141218/83cdd967/attachment-0001.html>