[Cmacc] technical design decisions

[Primavera De Filippi]

On Thu, Dec 18, 2014 at 7:19 PM, Jim Hazard <james.g.hazard at gmail.com>
wrote:
>
> 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.
>
>
In other words, CMACC is a syntactic data-model, and LegalXML could be
employed to add semantic information to the CMACC data-model. Does that
make sense?


>
>
>
>
> 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/*
> <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
>
>
> _______________________________________________
> Cmacc mailing list
> Cmacc at lists.commonaccord.org
> http://lists.commonaccord.org/listinfo/cmacc
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.commonaccord.org/archive/cmacc/attachments/20141218/8a7ffad8/attachment.html>