DID WG Topic Call on Property preservation rules for production and consumption — Minutes

Date: 2020-10-08

See also the Agenda and the IRC Log


Present: Ivan Herman, Markus Sabadello, Amy Guy, Justin Richer, Brent Zundel, Dave Longley, Jonathan Holt, Manu Sporny, Orie Steele, Adrian Gropper, Drummond Reed



Chair: Brent Zundel

Scribe(s): Amy Guy


Brent Zundel: the last call related to this, we made some decent progress toward consensus
… hoping to see proposals today that we can use to work toward agreement

Manu Sporny: to recap some of the proposals that passed during the last call

Ivan Herman: Minutes of the last relevant topic call:

Manu Sporny: Resolution #1: A DID Method MUST NOT add, modify, or remove from the production or consumption rules for a representation.

Manu Sporny: we had a lot of good discussion and were able to get to a couple of resolutions
… this means that a DID method can’t change the way the general production and consumption rules operate
… but they can do things after they’ve done that production or consumption, can post or preprocess as they see fit

Manu Sporny: Resolution #2: A DID Method may process the abstract data model in pre-production or post-consumption to enforce DID Method-specific rules and transformations.

Manu Sporny: the other thing that we agreed to was ^
… this means that if a DID method needs to do anything related to security to clean things up it can do that
… a DID method can modify things in that way

Manu Sporny: Resolution #3: The Working Group supports a general “preserve by default” design goal for the abstract data model. This means that a general rule for the abstract data model is to preserve properties that are not registered or documented anywhere, such as “foo”: “bar”, as long as the property name and property value datatype can be cleanly and losslessly consumed from a representation into the abstract data model and produced from the abstract data model to a representation. The WG may specify exceptions to this general design goal.

Manu Sporny: The third resolution was pretty involved
… in general the WG seemed to support a preserve by default design goal
… if you can pass it through, do

Manu Sporny: for properties like foobar which are not defined anywhere the general goal, which could have exceptions, is to pass those properties through
… we may end up specifying exceptions
… we stopped just short of picking up the last proposal

Manu Sporny: The last proposal was something to the effect of: A class of representation-specific key-value pairs will be identified in the specification that MUST NOT be preserved when performing production and/or consumption in specific representations. Examples might include things like @context and $schema.

Manu Sporny: was to basically create a class of representation specific key value pairs and say that those things should be preserved as they go through the data model
@context is representation specific so it should be eliminated before it gets to the adm so when a json production happens it doesn’t show up, it’s cleaned
… that’s where we got to
… i know drummond and markus and justin have been working on another proposal
… like always we’ll go ahead and put some proposals forward later on in the call to see where the group is

Justin Richer: to add to that, the context that what we’re talking about when we talk about a lossless transformation is lossless transformation of the DID document
… a lot of the arguments that were going to hopefully be resolving hinge around what is in the DID document that we are losslessly converting
… this informs what you do with unknown properties, what you do with representation specific markup
… and all of those other things

Jonathan Holt: I suppose I see a conflict between resolution 1 and 2.. if a DID method has conflicting information, the JSON-LD @context has changed, I’ve cached a different version of the JSON-LD than what was retreived, resolution 1 and 2 are in conflict
… how to resolve them?

Markus Sabadello: something about the term property
… we talk about properties and preserving properties and dropping properties
… properties appear to describe the subject
… there’s a relationship between the subject and those values
… that’s what the spec says right now
… things like @context or $schema or CBOR semantic tags are not properties
… they are representation specific constructs that make a certain representation work
… they are used in the production and consumption rules but not properties associated with the DID subject

Brent Zundel: they are two paths forward that’ iv’e heard mentioned
… one is to go over the proposal that markus, justin and drummond have been working on together
… the other path forward is to focus on the proposal manu mentioned

Orie Steele: I have also contributed to the proposal markus, drummond and justin have been working on

Manu Sporny: maybe we can get a quick read on the representation specific key/value pair thing
… not as an attempt to get a resolution, but see where the group is

Justin Richer: I support parts of the resolution text as manu did and I don’t want to try and wordsmith the exact text here
… i think there’s a difference in approach between the framing that manu has presented about not preserving specific properties and markus’ approach of defining more exactly what is a property of the document

Drummond Reed: sorry to join late

Justin Richer: and something that drummond has proposed within the last week i think might help clarify
… in the same way that having resolution metadata pulled out as a separate class of items that could be preserved inside the internal process and inform the resolution process in later steps
… the proposal is effectively to follow markus’ approach of define what is in the abstract data model and define another class of properties that are not part of the ADM with the net effect of saying don’t mix the two

Drummond Reed: +1 to not mixing the two

Justin Richer: it’s not about throwing them away or ignoring them, it’s about defining what they are
… that’s the key difference in approach

Brent Zundel: question on that - when you say define what they are, is that meant to be specific or categorically?

Justin Richer: a little of both
… define the category of things that are representation specific properties
… that you might want to keep around in case you need to reserialize things on the way out
… and then specifically have representations register their representation specific properties that they want handled in this way
… to make it concrete, @context would never go in the abstract data model but if you are consuming a JSON-LD formatted document you might very well want to keep the value of the @context field that you read in around

Orie Steele: See also https://github.com/w3c/did-core/issues/417

Justin Richer: it’s not part of the ADM because it doesn’t describe the DID subject, but you wouldn’t be forbidden from keeping it around and reusing if you go to produce a serialization in the future

Orie Steele: justin is starting to get into the meat of what for me has been helpful distinction between the concept of production, as the first time a VDR is processed and a representaton is first constructed in the abstract format then concretely presented in a representation
… and what i’ve been calling translation which is the process of consuming a representation into the ADM and producing another representation out
… even though mechanically these things may be implemented the same way it’s unhelpful to conflate them
… I’d like to define the way I see them and hear comments around how these things are related

Dave Longley: +1 to Orie, and they don’t have to be implemented the same way either

Orie Steele: For me translation means you’re starting with a concrete representation
… production means you’re starting with an abstract data model
… if you think about how did methods are implemented today, there’s a VDR and software that constructs an abstract representation,t hen provides a concrete representation
… I think that is separate from the process of translation where I hand you a DID doc in a concrete representation and you pass that out as another
… conflating them is causing confusing
… but both may abide by the same rules we have defined in DID core today

Drummond Reed: I agree that they can both work by the same rules

Orie Steele: there’s a lot of discussion in this issue and a helpful diagram by markus in 417

Justin Richer: I hadn’t seen that issue yet

Dave Longley: +1 to Orie, there are “artifacts” of representations worth preserving during translation that aren’t there during “direct production from the ADM”

Justin Richer: the summary of my thoughts is that this translation step is really a combination of several things if you are truly using the methods defined in DID core to accomplish it
… in that it’s the combination of a consumption fo a representation followed by the production of a representation that is going to be different
… that’s to me the translation has always been that combination of functionality
… looks lke that’s exactly what markus has in this diagram

Drummond Reed: Link to Markus’ diagram?

Markus Sabadello: Diagram

Manu Sporny: I’m having a very hard time following the discussion about the nuance of splitting apart and putting it together

Markus Sabadello: Better link to diagram: https://github.com/w3c/did-core/issues/417#issuecomment-703713256

Manu Sporny: I don’t understand what the difference is in the end result
… also the first time I’m seeing this issue

Drummond Reed: thanks

Manu Sporny: Could someone who has been involved in the discussion explain what the breakthrough over the past week?

Justin Richer: manu: can you define the “this” that’s being split apart?

Manu Sporny: the end result concern is that there are certain types of round tripping that would be forbidden based on what is being proposed
… meaning context is dropped and you can never recover it
… that’s a concrete example of a problem
… has that issue been addressed?
… or does that issue still remain?

Drummond Reed: if someone wants to directly answer … i’m happy to defer and come back after manu’s question is answered

Justin Richer: that’s what I was saying earlier, this has never been about just dropping @context
… if you see it on the way in and you understand it
… on the JSON-LD side you’re getting a JSON-LD document and processing the @context
… it doesn’t go in the abstract data model but that doesn’t mean you are forced to forget it existed
… it means as you are processing the properties you are processing them in the context of @context so you know which property names go to which named properties of the abstract data model and their types and so on
… doesn’t mean you have to forget you saw it, just means it is not a property of the abstract data model

Dave Longley: what justin_r is saying is sounding good so far …

Justin Richer: what drummond has written up calls that out more in that it creates an additional bucket for representation specific information that a processor could keep around

Drummond Reed: I will cover what I wrote up when my turn in the queue comes

Justin Richer: this also allows you to .. gives you a logical place to think about where you would put this information if you were creating JSON-LD whole cloth which is what the production rules are about
… going from the data model into a representation
… if you’re doing that in JSON-LD you need an @context field and you’er not going to be getting it from the data model
… so you have to come up with them or maybe someone has handed you one as a representation specific field and you can look at that and understand that it’s okay to reuse
… that last bit is important
… if you’re reading @context in the context of a plain json document then you’re not properly processing @context and you’ve got an errant field
… that’s the type of error case we’re trying to prevent against with this language

Orie Steele: I review markus and drummond and justin’s proposal and absent a few sentences I object to, I am generally in favour
… I think it’s helpful to define adm properties if you need a bucket that applies to representation specific properties
… parts of their proposal help tease that apart
… the thing i want to .. it would be helpful to talk about production as a function fo the VDR vs production as a function of some intermediary that starts with a concrete representation
… it’s possible we’re reacting to what we believe might be being asserted but might not be being asserted

Drummond Reed: Ivan, the last proposal is brand new; I just wrote it up last night, I will cover it next on the queue

Orie Steele: i heard properties aren’t getting dropped as part of translation, that’s great if that’s true
… I don’t see any reason they should be dropped

Manu Sporny: +1 to what Orie is saying…

Orie Steele: if they need to be put in a bucket of properties preserved that’s fine with me
… maybe there’s concern around production rules for json specifically
… the way I see it is for producing a json DID doc you have an ADM, it’s got a number of field, represented via map, you take that ADM which you could have constructed in many different ways and make that ADM a JSON object
… at that point in time if you read the spec the way it is today it must not contain an @context
… if you accept the PR i added, it can contain an @context
… microsoft and google both return JSON-LD as applicaton/json

Justin Richer: +1 to breaking bad mime types from microsoft and google

Orie Steele: if this WG goes against that pattern it’s going to be problematic
… we don’t need to say anything in the json representation about JSON-LD
… we say it’s an infra map

Drummond Reed: Agreed. As they say, “I’m dancing as fast as I can”, i.e., it was produced last night in preparation for this call, so it’s not really a “proposal” yet, but a potential proposal for discussion today.

Dave Longley: justin_r, i think it’s way too late to fix that issue

Orie Steele: once you have a json representation of a DID doc - not that it must contain an @context, it doesn’t need to, can have arbitrary properties, can do whatever it wants, it’s json
… the point I’m making is the DID method is responsible for that first production and it’s a function of the VDR
… what happens next is translation

Manu Sporny: I’m very much on board with what Orie is saying right now….

Manu Sporny: very concerned about what justin_r just said :(

Dave Longley: yes, +1 to Orie

Orie Steele: if we go from what a DID method has produced to takin a concrete representation and creating another representation that is translation
… that second thing needs to preserve those properties because it doesn’t have the authority to change what the DID method did in the first place

Jonathan Holt: +1 The CBOR section says that if MAY contain @context and has the same semantics as JSON and JSON-LD.

Manu Sporny: @context in application/json is a very strong reality today

Drummond Reed: DID methods don’t produce DID documents, DID controllers do

Orie Steele: s omewhat malicious to mutate what the DID method produced
… JSON DID document section shouldn’t talk about JSON-LD
… we should preserve properties by default
… translation should preserve properties by default
… if we need to put properties in buckets I’m fine with that
… as long as the DID method has the choice to produce JSOn that contains representation specific properties or not, I’m fine with that

Dave Longley: +1 to Orie, i think what he just described matches reality and is the easiest thing for implementers to deal with

Orie Steele: i would be in favor of reviewing the joint proposal.

Justin Richer: dlongley: people said that about google’s OIDC implementation but they did fix it when the community pressured them

Markus Sabadello: I agree with orie that it’s helpful to distinguish between the DID doc that comes out of the VDR when you originally execute the read operation of the DID method

Manu Sporny: justin_r, you’re presuming they’re wrong… they’re not.

Manu Sporny: They’re doing the right thing… it’s not a mistake.

Markus Sabadello: you execute that according to the rules of the DID method and get a DID document
… you can produce a representation from the DID doc

Manu Sporny: It was a conscious decision… I think that might be the miscommunication here…

Markus Sabadello: I also agree that translation can be thought of as consuming and producing another representation
… and agree about the plain JSON production rules, that should take all the properties in the infra map from the ADM and turn that into a JSON object
… I agree with Orie’s pull request that removes all mention of @context and JSON-LD from the pain json production rules

Justin Richer: manu: then why is there a different mime type at all? strongly disagree with that stance

Markus Sabadello: correct to say the plain JSON production rules should take the property map of the ADM and turn that into a JSON object

Manu Sporny: justin_r, I’ve put myself on the queue to explain.

Markus Sabadello: what I don’t agree with is that this map in the ADM would ever contain an @context because it’s not a property of the DID subject

Justin Richer: manu: html is ostensibly just text but text/plain and text/html are different because of the semantics

Markus Sabadello: we’re not dropping it, it just never ends up there

Justin Richer: a text file can contain html but html has special meaning. it’s the same here

Markus Sabadello: what googles and others are returning JSON-LD when they are being asked for JSON we have decided not to do that
… we have decided we will have JSON and and plain JSON

Orie Steele: “we” have not decided… we are “deciding” :)

Markus Sabadello: the example of google is not really valid and applicable
… they just support one thing, not multiple representations
… we are supporting JSON-LD and JSON
… if i execute the resolve representation function to produce plain JSON DID do I don’t expect an @context in there, why would someone add that

Drummond Reed: Link to proposal discussion: https://docs.google.com/document/d/1TsEWUIQCxJdvj-9-Mt2CHwyByCCVaielx7KVBCiLJXs/edit?usp=sharing

Drummond Reed: something I wrote up last night… thinking through this challenging issue
… I had the aha yesterday .. we have these two worldviews… noone is right or wrong, just different ways of saying what is important
… we also said we know we want to separate data and metadata
… we want to put metadata outside the did doc … the reason @context has turned into this flash point is it doesn’t describe the DID subject but it’s metadata about the representaton that has to go in the DID doc
… the ADM classifies two groups of properties, subject properties and representation properties; the latter hast o be defined by each representation, required or optional, but they define it, and we register them all
… so you know what representation properties are and new representation properties are going to be there and you know it
… that’s the rules around registration
… as just in was summarising earlier, production rules are you do what markus said
… you’ve gotta serialize it in your representation, and i know what to do with it because of the production rules
… you know in the end what properties describe the did subject and what are needed by representations
… that provides the semantic clarity we need and provides the property preservation we need
… it does mean we have to have a category in the registry for representation properties

Brent Zundel: I think that a category called “representation specific properties” may not be inclusive enough.

Drummond Reed: and the DID controller to support different representations they have to provide the properties need it

Orie Steele: hmm it may not be the did controller

Orie Steele: it is likely the did method

Drummond Reed: if they only want to support json they don’t have to provide any

Orie Steele: for most did methods

Justin Richer: +1 to drummond’s proposal

Orie Steele: +1 generally

Manu Sporny: the fundamental issue is not being addressed, which is whether or not @context belongs in application/json or not
… here is the argument for why it belongs
… there are a number of implementations that will process @context, not as JSON-LD, but something that is a check on the data that you’re getting in
… Our software will take something in and it doesn’t care if it’s application/json or ld+json, it will do a JSON schema first level check against it
… checks to make sure @context has the values it’s expecting in the order it’s expecting - this is just plain JSON checking
… that is an example of @context being used in a JSON only processing pipeline in a useful way
… many other organisations do that, google and microsoft are among them
… . the idea that @context is useful only inside an application/ld+json document doesn’t match reality
… making it difficult to impossible to carry that information through to application/json goes against reality right now
… fundamentally that’s it

Justin Richer: what manu is describing is neither production nor consumption by these definitions

Manu Sporny: it’s not clear to me that justin’s position is the same as markus is the same as drummond as this… I’m hearing markus agree more with Orie than with justin
… I think justin has been very clear
… I’m having a hard time understanding how the proposal impacts whether or not we throw @context or not for application/json

Justin Richer: I do not want to throw it out. I don’t want it to be there.

Drummond Reed: yes, it is preserved

Orie Steele: my interpretation of it is it is preserved because you have created a category called representation properties which must be preserved
… if @context is not a member of the ADM how does JSOn-LD production work? this answers that question. The JSON-LD production constructs an @context member, adds it to the ADM, and do the same thing the JSON produce is doing which is make a JSON object
… this answers the question because you can see this @context member, preserved as part of the initial production, and also preserved as part of translation when a representation comes through that has that property

Drummond Reed: Orie is correct, this proposal does maintain any property in the ADM because the ADM now includes both subject properties and representation properties.

Orie Steele: to be clear, if someone hands you a jSON object that doesn’t contain an @context you can translate that to a CBOR which doesn’t have an @context, but you can’t translate to JSON unless you assume an @context which I think is a mistake

Manu Sporny: +1 assuming an @context would be a huge mistake.

Orie Steele: what we now have to discuss is I’m handing you a JSON doc with no @context, consumption into the ADM, and now I want to do production> What can I produce?

Justin Richer: assuming @context is the only way to produce JSON-LD from scratch, no?

Orie Steele: I’m totally fine if the answer is you can’t produce JSON-LD from a JSON doc without an @context. THat makes logical sense to me
… you don’t want to mutate the intention of what the DID method creator had expressed. It would be wrong for me to assume that I understand what the context is if the DID method didn’t include one

Manu Sporny: justin_r, only if you know you are the very first producer.

Orie Steele: I shouldn’t be doing that, it’s a security and separation of concerns issue
… but generally a fan of this proposal

Jonathan Holt: in the CBOR section I wrote it may contain and has the same semantics as JSON/JSON-LD. The key difference here is both the consumption and the mandated processing.. I’m fine with it being there, ultimately gets into is it unambiguously clear what the semantics are
… in perl the need for syntactic sugar.. plenty of examples in regex where there’s syntactic sugar to augment the meaning and constraining what the type is. I see @context being the same thing for semantis.. it’s semantic sugar
… it facilitates the ease of translation from one encoding to another
… very mch analogous to the CBOR tags in extensibility of CBOR
… you prepend with a tag, it doesn’t belong in the ADM but facilitates the ease of translation from one encoding to another
… tag 23 is a syntactic tag that what follows is binary but when you translate to JSON it should go to a hexadecimal representation
… CDDL maps to abnf rules, it is a normative spec with normative mappings
… I did find that the URI is pointing to an RFC normatively referenced but the tag is optional
… if you prepend it with a tag it gives a syntactic sugar as far as what this thing means and how it’s constrained to be a URI
… I think the same thing here
… we can get most of the way there with the structure and the meaning
… I had to look up what an ADM means
… it’s a class of objects whose logical behaviour is a set of values and a set of operations
… breaking this up into values and operations - algorithmic transformations - we can get through this

Markus Sabadello: a few minutes ago orie was talking about the process of what would happen if you start with a plain JSON and go to JSON-LD
… I think it’s helpful to think about this… use cases like this are one of the reasons we have the ADM and the registry
… a plain JSON DID doc does not contain an @context, can be losslessly converted to JSON-LD using the information in the registries

Orie Steele: I don’t believe its possible to “safely” produce JSON-LD from JSON.

Markus Sabadello: the plain JSON DID doc would be consumed to the ADM and produce the JSOn-LD representation using the ADM and the information in the registries, that’s how you can construct the @context which goes into the JSON-LD representation
… One simple view on this.. if we say that JSON-LD contains @context and plain JSON can also contain the same @context, what’s the difference?
… why do we need two? We should merge them

Orie Steele: there is a difference, JSON is JSON… JSON-LD is RDF as JSON.

Markus Sabadello: we should even have a rule that if there are multiple representations then they must not be byte to byte equivalent

Orie Steele: they are clearly not equivalent

Markus Sabadello: if we want that… personally I would think it’s not a bad idea.. but then it’s just one representation, it’s not two different ones any more

Drummond Reed: the key difference between JSON only and JSON ld representation is that @context is required in the JSON-LD representation and it’s clearly optional in the JSON only representation
… if according to the proposal the DID document author/controller wants to have an @context property as a representation property they can do that and it would appear n the JSON representation
… but if they didn’t want or need that they do not have to
… we have plenty of folks talking about the need for plain JSON that doesn’t have an @context
… that’s the reason for keeping them separate
… but this proposal does say if you want to have @context and you want it to be an option then they can include it
… yes you can definitely roundtrip between all representations
… that the DID document author, controller, decides they will provide the representation properties for
… the two things this proposal requires is we establish a separate category of controllers in the registry
… that’s no different than today, you want to use a representation you have to provide metadata for the consumption rules
… if you want to roundtrip between formats you have to provide properties for that format
… and will all be preserved in every direction

Brent Zundel: manu brought up the point that an @context in a JSON document can be used by a JSON processor for some quick checking
… having two buckets in the ADM, one ofr subject properties and one for representation specific properties, the latter may not be a large enough bucket
… if JSON wants to use an @context as a processing properties that wouldn’t fit in the representaton bucket

Drummond Reed: I’m fine with calling the ‘representation-specific properties” to call them “processing properties”

Brent Zundel: what if there’s a DID method that includes a processing property, that’s mthod specific not representation specific. Would that enlargement of the bucket help things at all?

Orie Steele: that totally stole the thing I q’d for
… JSON is not JSON-LD without an @context
… JSON-LD has certain restrictiosn to do with alignment to RDF, JSON does not
… I can include a JSON object n my DID doc that has no representation in RDF that’s valid
… in terms of converting because you can read the registries… that is not true, you will not be able to do that
… the resaon is JSON interpretation of the registries is not defined
… they are only defined in terms of JSON-LD
… the problem that needs to be solved is how do I interpret JSON objects with no RDF representations that must be represented as JSON-LD
… I don’t think we can solve that
… and would destroy the value of JSOn to restrict JSON to only being JSON-LD without an @context
… I strongly object to JSON as a separate representation if that’s what we’re trying to do
… I need to be able to put objects in there that aren’t rerpsentable as RDF

Drummond Reed: I was going to say that SOME JSON-only DID documents—those in which all the DID document properties are defined in the Registries—could be converted to JSON-LD. But if a property is not registered, then it can’t be automatically converted from JSON-only to JSON-LD.

Orie Steele: most of the wayt he spec is written is associated with RDF interpretations o fJSON which don’t fit with arbitrary JSON structures like objects nested in arrays nested in objects that aren’t RDF

Drummond Reed: …without an @context

Orie Steele: it’s worth considering if JSON is really it’s own representatoin. What does it mean for translation to JSON-LD?
… I’m asserting it’s impossible

Dave Longley: i agree with Orie and think that we’re fighting a battle we don’t need to fight and we should unify

Manu Sporny: I’d like to run a poll..

Manu Sporny: POLL: DO NOT allow @context to exist in application/json representations.

Drummond Reed: -1

Dave Longley: -1

Orie Steele: -1

Amy Guy: -1

Justin Richer: -0

Brent Zundel: -1

Manu Sporny: -1

Ivan Herman: -1

Adrian Gropper: 0

Markus Sabadello: 0

Jonathan Holt: -0

Manu Sporny: POLL: Allow @context to be expressed in application/json representations.

Manu Sporny: +1

Amy Guy: +1

Orie Steele: +1

Dave Longley: +1

Drummond Reed: +1

Justin Richer: -1

Brent Zundel: +1

Jonathan Holt: +0

Adrian Gropper: 0

Drummond Reed: not required right?

Manu Sporny: correct

Ivan Herman: +1

Markus Sabadello: 0 those are the wrong questions to ask.. the right questions would be whether the production rules add @context or not

Justin Richer: ^– what Markus said

Dave Longley: markus_sabadello, yes, but that’s whether or not @context is required vs. it being optional

Jonathan Holt: does consuming applicaton/json+ld require JSON-LD processing?
… concerns about the conflict that could arise if you’re getting a MITM attack or dont’ have the proper cached version of the @context file

Orie Steele: markus_sabadello justin_r if the DID Method has an ADM, with an @context it would be produced… for JSON only, they would not be required to do so

Drummond Reed: it is optional and it becomes the DID document author’s choice in the representation if they’re going to use a JSON only representation whether they put an @context or not

Orie Steele: the DID controller does not control representations

Drummond Reed: want to clarify that this proposal we wrote up is about their choice to do that?

Orie Steele: a DID method controls them generally, only a few did methods allow a controller to control representation

Brent Zundel: -1 to DID Document controller adding @context. I see it more as a DID Method thing

Markus Sabadello: agree if we have a JSON representation it should allow any arbitrary JSON

Orie Steele: did:web is a good example of a method tha allows a controller to control the representation

Markus Sabadello: if we support plain JSON it must be possible to have any arbitrary structures in there and sometimes it may not be possible to convert that losslessly

Orie Steele: agree with markus generally

Markus Sabadello: which is fine.. we said lossless conversion is only gauranteed for registered properties
… if you don’t have reigstered properties they may not be losslessly converted

Brent Zundel: the meeting is officially over..
… thanks all

Drummond Reed: Again, the Google doc link for anyone who wants to review/comment on the proposal: https://docs.google.com/document/d/1TsEWUIQCxJdvj-9-Mt2CHwyByCCVaielx7KVBCiLJXs/edit?usp=sharing

Orie Steele: thanks!