Meeting minutes
Minutes
<kaz> May-25
<mlagally> https://
reviewing minutes, notes about JSON Schema, using version 7
Lagally: point is there is another spec for validation that includes particular formats like date-time
Lagally: there is an issue, see minutes
… issue #209 in wot-profile
Lagally: approve?
Lagally: no objections, approved
Cleaning up
PR #203
<kaz> PR 203 - Cleanup core with baseline / information model
Lagally: replace "core" with "baseline"
… some comments from bf about other changes needed, ml wanted to limit scope
McCool: are "baseline profile" and "HTTP baseline profile" different>
Lagally: yes, a little inconsistent
Ege: not a small issue, Baseline = core, but HTTP Baseline is more specific
Lagally: this PR is a cleanup pass, not a reorg
McCool: still, would it be possible to fix all ocurrences of "Baseline" to "HTTP Baseline"?
Lagally: propose we do that in another iteration
McCool: ok, but need an issue
Kaz: I'm OK with that but we should fix the spec asap
McCool: bottom line is we agreed to use "HTTP Baseline Profile" only, so any use of "Baseline Profile" is a mistake and needs to be fixed
Lagally: creates issue #210
<kaz> Issue 210 - Consistent use HTTP baseline profile
Ege: image also needs to be updated
Lagally: as image has other problems, will create another issue for that
Lagally: creates issue #211
<kaz> Issue 211 - Image update for HTTP baseline profile
Lagally: assigning both to ege
McCool: how exactly should figure be updated?
Ege: is it generic, or for a specific profile?
McCool: I think this depends on the context of the text; the current text is specific but if we edit it to be more generic, figure will change in different ways
Lagally: also a large section marked as at-risk; the data model
McCool: this was the section that bf was concerned about?
Lagally: yes; so is in there, but marked as being at-risk, with reference to the issue where it is being discussed
McCool: anyway, ok with merging this PR for now, even if imperfect
Issue #200: Length and size limits
Issue 200 - Revisit length limits
Lagally: length limits and constraints
Lagally: agree these values are arbitrary...
… let's talk about whether we want constraints or not
McCool: couple of thoughts; interconversion to/from; constrained devices; TM constraints
Lagally: example, ids that exceed length limits, first 512 are identical
… that would break use cases
… so these constraints are a contract, compliant things must not provide longer values
McCool: and even high-end systems, e.g. relational databases, may have finite limits
McCool: think we should lay out use cases; I see three, interconversion, constrained devices, and other systems with limits (databases)
… interconversion though is very difficult, may be many format in conflict with each other
Ege: agree that interconversion raises a very complicated set of issues
… think we should drive with basis on constrained devices and databases
Ege: btw prog langs don't make sense a driver of limits, tend to be very high
… need to look at other constraints, e.g. relational databases
… also watch out for "bytes" vs "characters"
McCool: should use UTF-8 and bytes
Ege: need to relate to JSON string lengths
Kaz: can think about this by ourselves, but might want to talk to other SDOs, i.e. IETF, OneM2M, etc.
Lagally: did give a couple of spec references
McCool: not only what limits are, but how they are defined, e.g. bytes vs chars
Kaz: also IEC dictionary people
McCool: right, UTF-8 "character" can expand to up to 4 bytes in memory...
Lagally: agree that bytes are better, less confusing
McCool: and also gives a tighter limit
Ege: JSON validation is troublesome, may need a special validator
Lagally: ok, let's go with bytes, let's start with a strawman
<kaz> [adjourned]