Page Comparison

...

1. Once the above is complete, find and replace the terms in the CR, Update the terminology and definitions with the above specified information to produce a sub-specification - for the new law.  
   1. On interoperability 
      1. Former user (Deleted) raises potential issue that might break spec if fields are changed -so want to be careful and think through first before deciding on what to actually call the out put .. - aka avoid in appropriate. fragmentation  
         1. there might be a nice json (although not tied to json) way around this issue in schema 
         2. alternatively, general idea originally for  interoperability was the rendering of any version mapped to the iso version into the Iso version for receipt viewing purposes. 
            1. action is to review similar use cases and talk to people about this. 
               1. HyperLedger project uses layers which are standard modules types that depend on a base layer
               2. so a extension could be interpreted as providing the base layer for an industry or sector.  
         3. in terms of GDPR and other countries - field names that have the wrong definition inherently like pii_controller, will need conversion work - but I sense that their are strong sentiments and differences in privacy laws from country to country to be sensitive of /. (like being bi-lingual in Canada)
            1. potential option.  making field names generic so they work for all laws_ note differences from basic term and notate the generic definition using context and semantics.  
         4. Need to differentiate a legal/format cr extension and a technical extension when talking about this i.e. json, json_ld version type of discussions and legal_field requirements their use/definition -   perhaps these are conflated and need separate consideration?
         5. This extension kit is intended to be very narrowly focused on legally explicit consent records and receipts, so that it can be expanded if required designed to help create a point from which authoritative scopes of work can be supported.   As well as generate communal assets for its use and adoption. i.e. documentation. 
            
            1. 1. the work towards authoritative record and receipts, proof of notice and consent requirements need the legal field labels - as for the field names - there does seem to be some nuances where some maybe most fields can stay the same. either way - it would be nice to not have this limitation and just be able to render any extension specification to the international version?   
            2. There is a doc that was just shared to another group called "SHTI200-0008_Policy Management Standards Enabling Trustworthy pHealth-3" based on an interop spec for complex systems -  looking into this 
      B. Requirements 
      1. additional or derivatives specification must add to, not fragment specification work
         1. contributing extra fields and their definition to the CR spec with extensions can be as simple as addition extensions and fields to a single document or wiki page