Meeting minutes
Minutes Review
<kaz> Oct-20
Sebastian: (goes through the minutes)
Sebastian: SSML recomendation 1.1 do they say backwards compatible?
Sebastian: XML also uses the old namespace (between 1.0 and 1.1)
Sebastian: any objections?
F2F Minutes Review
<kaz> Oct-28
Sebastian: manu sporny recommended to go with a new namespace
Cristiano: we are constraining the validation to validate the string in the context
Cristiano: context points to terms you can use. if 1.1 context just extends 1.0 it is ok?
Cristiano: is it ok to check for the exact url?
Sebastian: you are right, from json-ld perspective it is fine
… but a json processor would have problems
<Zakim> kaz, you wanted to suggest we discuss the detail AFTER the minutes review
Sebastian: any objections to make the minutes public?
<kaz> (none; approved)
TD Versioning
<kaz> TD spec Abstract section
Sebastian: maybe we can add information on how to convert 1.1 to 1.0
Ege: we can say 1.1 can process 1.0
McCool: that would be forward compatibility
Cristiano: we should do this carefully and stick to it in the next versions as well
Ege: we can define that validation is not mandatory
Cristiano: is it not mandatory?
Ege: it is not I think. So we can say that the backwards compatible does not mean validating new documents
Sebastian: we can say that for the new features, you have to update your software
<kaz> JSON-LD 1.1
Ege: but in conventional software, you don't have to update the code that uses a library if that library gets a minor version update
<kaz> JSON-LD 1.1 Processing Algorithms and API
Kaz: json-ld also had problems with versioning so we can look at their specs. We should think about what want to do for "compatibility" between TD 1.0 and TD 1.1 first, and then think about what kind of versioning mechanism is required for that purpose.
Kaz: I'm not suggesting we also generate a separate spec for TD 1.1 processing, though.
Sebastian: michael koster, how does sdf handle this?
mk: for new features, you need to update the document and the processor
mk: if you realized them, you can ignore them. called softbreaking
Cristiano: I think we are getting somewhere
<McCool> (sorry, I have to go...)
Cristiano: we do not change, e.g. title from string to object
Sebastian: adding profile keyword would mean that there is another behavior but that is not breaking
Daniel: we should be jsonld 1.1 compliant (I am not sure if I understood)
<cris> +1
Ege: maybe we can say that we add new terms, do not change the structure of the old terms but add new values. This means that if a TD parser was iterating through a key's values, it will not fail but it will meet new values.
… so for example, op will be an array and can be iterated through like an array but will have new values like `subscribeallevents`
… maybe @context needs some special note
Sebastian: any objections?
Kaz: we should change the namespace maybe
Kaz: don't object to the summary but as already mentioned during the DID joint call on Oct-28, maybe https://
Action: kaz to ask the JSON-LD guys for advice again
TD Roadmap
<kaz> wot PR 1000
Sebastian: (goes through the plan)
[[
0. Clarify which normative features in the TD 1.1, Architecture and Profile should be covered by mid-Nov
1. Roll back TD spec to 1.1 (1.0 compatible) features by Nov 30
2. Normative features freeze TD 1.1 & Architecture spec by Dec 15
3. Get wide review including TAG, Accessibilty, Privacy, Security, and Internationalization to review TD 1.1 draft
4. Normative features freeze Discovery spec by Dec 15
5. Feature freeze Profile spec by Jan 31
6. Testfest in mid-Feb
7. CR transition in mid-March
8. PR transition in mid-April
9. REC transition before end of extended charter end of July
]]
Sebastian: any comments?
… need to defer some of the features for TD 2.0
… normative features for TD 1.1 to be frozen by Dec 15
PRs
PR 1205
WIP: Fix issues in TM schema generation script #1205
Sebastian: (goes through the changes)
… would recommend we merge this PR
Kaz: one problem due to Ege's review
Ege: reverted
Sebastian: and merged the PR 1205
PR 1207
<sebastia_> Updates for TM Chapter #1207
Sebastian: moved the content to the Architecture spec
Ege: regular expression based on ECMAScript
Kaz: do we have sufficient implementations for TM features in general?
Sebastian: we already have multiple implementations
Kaz: in that case, we need to update the test results
Ege: right
preview of "10.4 Derivation to Thing Description Instances"
Sebastian: two options for TD generation
… single derivation or multiple derivation
Ege: we can merge this PR 1207 and add fixes later
Kaz: note that there is a typo
… "Please not that ..." should be "Please note that ..."
Sebastian: have issue with direct change within the PR
… because we need to regenerate the index.html based on the index.template.html
… let's fix the typo as well later
… (merges PR 1207)
Issue 1265 to fix the remaining issues
PR 1254
Sebastian: fixed Issue 1247
Allowing type to be an array #1247
Ege: should update the text for PR 1254
Sebastian: (records a comment we should not merge this for TD 1.1)
PR 1257
Add op values description table #1257
Sebastian: (merged)
[adjourned]