...
- 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.
- On interoperability
- 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
- there might be a nice json (although not tied to json) way around this issue in schema
- 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.
- action is to review similar use cases and talk to people about this.
- HyperLedger project uses layers which are standard modules types that depend on a base layer
- so a extension could be interpreted as providing the base layer for an industry or sector.
- action is to review similar use cases and talk to people about this.
- 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)
- 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.
- 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?
- 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.
- 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?
- 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
- additional or derivatives specification must add to, not fragment specification work
- 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 should increase specification scope.
- 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 should increase specification scope.
- 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
- On interoperability