Michael Grosser

The direction you are proposing is to basically not define meta data or if it is defined, as a separate meta data definition. I think this leads to more complexity...

>> The direction you are proposing is to basically not define meta data > Exactly this. Just to clarify. You don't wanna define any meta data or just no last...

The permalink issue is something for a separate issue. If you feel that should be discussed, please open a separate issue. It's not just the complication introduced into the tooling,...

I do understand both solutions and I still think it is cleaner to define it within the spec. Then tools know this should be used and smart users wouldn't check...

I do like your persistence and will remove the date field in the next revision. So the basis of the discussion is on the conservative side.

When we decide on lastModified being an implementation detail, we should remove it. One can always add it optionally, but not supporting it = removing it.

So action here: * [ ] Remove ```lastModified``` * [ ] Close issue * [ ] Revisit issue post-v1

In my personal opinion I see the value of those, but they don't map well to the general projects. As the schema allows for optional fields, these might be better...

Clarification. I meant optional in terms of addition to each personal schema and most likely not something general enough to be included into the schema, but as I said happy...

edit: No issue as bibJSON is also ISO8601 compliant. If we move to JS date objects (#199) we would introduce 2 different date handlings. bibJSON uses a string and we...