– DRAFT –
WoT-WG - TD-TF

I18N review

Issue 1416

<Ege> https://github.com/w3c/wot-thing-description/issues/1416

Ege: would clarification about this issue

Addison: if there is direction metadata, you should use it
… it's complicated

Ege: do you mean this part is complicated?

[[
The computation of the base direction of all human-readable text strings
is defined by the following set of rules:

* If no language tag is given, the base direction SHOULD be inferred
  through first-strong heuristics or detection algorithms such as the
  CLDR Likely Subtags [LDML].

* Outside of MultiLanguage Maps, the base direction MAY be inferred from
  the language tag of the default language.

* Inside of MultiLanguage Maps, the base direction of each value of the
  name-value pairs MAY be inferred from the language tag given in the
  corresponding name.

* In cases where a language can be written in more than one script with
  different base directions, the corresponding language tag given in
  @language or MultiLanguage Maps MUST include a script subtag, so that
  an appropriate base direction can be inferred. An example is Azeri,
  which is written LTR when Latin script is used (specified using az-Latn)
  and RTL when Arabic script is used (specified using az-Arab).
]]

Addison: yes

McCool: regarding the metadata
… JSON-LD guys make the standard
… so we followed that precedent

Issue 1414

<Ege> https://github.com/w3c/wot-thing-description/issues/1414

<Ege> https://www.w3.org/TR/json-ld/#base-direction

McCool: we fetch the context for TD fragments as well

Ege: should we scrap the complicated algorithm part?

McCool: should not simply scrap it due to backward compatibility

Addison: still think the last bullet is problematic

[[
In cases where a language can be written in more than one script with
different base directions, the corresponding language tag given in
@language or MultiLanguage Maps MUST include a script subtag, so that an
appropriate base direction can be inferred. An example is Azeri, which
is written LTR when Latin script is used (specified using az-Latn) and RTL
when Arabic script is used (specified using az-Arab).
]]

Addison: but if you could improve it for TD ver. 2.0, that's OK

Kaz: can we live with the current text for ver. 1.1?

McCool: no. need to add a new assertion
… suggest we draft a proposed assertion for it

Addison: you can draft a proposal and put that into this issue 1416

Kaz: tx

Issue 1411

<Ege> https://github.com/w3c/wot-thing-description/issues/1411

Addison: it's editorial
… would be better to show the value as non-display code
… e.g., ON and OFF

Ege: ok

Issue 1414 (revisited)

<Ege> https://github.com/w3c/wot-thing-description/issues/1414

Ege: any disadvantage about this

Addison: ok
… you'd be needing an additional option

Issue 1412

<Ege> https://github.com/w3c/wot-thing-description/issues/1412

Ege: possibly different PDFs based on languages

Addison: some documents have one-on-one language
… English, French, German, etc.

McCool: would follow the standard

Addison: HTML has an attribute to specify language, though

Ege: (adds a comment to the issue)

Issue 1415

https://github.com/w3c/wot-thing-description/issues/1415

Addison: would encourage content authors to use valid language tag
… recommend you go through your document carefully
… and link to our term "well-formed language tag" in the I18N Glosary

McCool: map this to our basic and full validation, where basic is well-formed and full is valid tags

Ege: TDs SHOULD provide vlid tags but consumers are not required to check against IANA registry (well formed is ok)

Issue 1410

<Ege> https://github.com/w3c/wot-thing-description/issues/1410

Addison: JSON files use UTF-8
… when comes to directory naming, we did some work on EPUB
… everything you do should be UTF-8
… you probably mean more like URI spec
… when you use link for somewhere
… maybe have a closer look

Ege: not exactly clear

Addison: might need further discussion

Issue 1413

https://github.com/w3c/wot-thing-description/issues/1413

Ege: I'm also confused with this

Addison: you don't provide features allow a Thing to indicte what languages are available for language-negotiation, etc.
… all the devices can use language-negotiation?

<cris_> btw https://tools.ietf.org/id/draft-ietf-json-rfc4627bis-09.html#rfc.section.8.1 JSON default encoding is UTF-8 but the rfc does not strictly forbid other UTF encondings

Ege: sort of understood
… for that purpose, we need new feature?

<addison> RFC4987

Addison: you could use language range
… not sure what would make sense, though
… this is more a feature request
… need to leave
… if you need further help, could continue the discussion on GitHub or another call

Ege: tx
… we'll create PRs

Addison: cool

Issue 1410

https://github.com/w3c/wot-thing-description/issues/1410

Ege: (adds comment)

[[
We should discuss whether it is OK to have spaces instead of URL
encoding (ege guesses that they should be URL encoded)
]]

Issue 1413 (revisited)

https://github.com/w3c/wot-thing-description/issues/1413

Ege: (adds comment)

[[
This is more like a feature request but a TD can describe the supported
locales as individual keys or language ranges (there is an RFC for that).

Another option would be to additionally list locales for a given
language (with a new keyword?)
]]

Issue 1411 (revisited)

https://github.com/w3c/wot-thing-description/issues/1411

Ege: (adds comment)

[[
Call of 02.03: This is simply about having more obviously code-related
names for "On", like "ON"
]]

Issue 1409

<kaz> Issue 1409 - No reference to Thing Model Schema for Validation

Ege: there is no reference to the TM schema in the spec
… I plan to add that before section 11.2 or at the bottom of section 11
… just the link not the actual schema

Daniel: ok to put just the link

Ege: yeah I don't like having a long schema file

Cristiano: why don't we just link when we describe what is a TM?

Ege: yeah right, I found the perfect place

PR 1419

<kaz> PR 1419 - Add auto value for the in field of SecuritySchemes

Jan: may I ask to add two item in the agenda? issue 1407 and PR 1419

Ege: I had an internal discussion about 1419 but we think is not really an elagant solution

McCool: we should fix it in TD 2.0
… we are choosing this solution just to not break backward compatibility

<Zakim> dape, you wanted to approving minutes?

Daniel: another agenda item: minutes approval

Ege: pr has minor issues but I'll keep it open for further reviews

Jan: can we indicate that the feature is still a draft
… or a workaround

McCool: it is not a real workaround

previous minutes

<kaz> Feb-23

Ege: as usual we discussed different issues from TD and in binding template we welcomed a new contribution about bacnet binding

Ege: any objections?

Ege: ok minutes approved

Issues

Ege: some of the issues are easy and they are in the agenda just to close them

Issue 1404

<kaz> Issue 1404 - ObservableProperties: unspecified operations, missing vocabulary terms

Ege: shortly observeproperties are under specified
… imho it is and edge use case
… if needed people can create an event

McCool: observe is closely related to properties
… I agree that it is not a bug but a feature... we should keep this simple

McCool: is this a 2.0 discussion? it might take time to implement this

Cristiano: I agree

Issue 1408

<kaz> Issue 1408 - Actions with cancel and query operations, the meaning of input and output, dynamic href

Ege: we introduce query and cancel action operation
… in profile we are using the operations

Ege: we need more examples

Ege: we don't support dynamic ids
… the issue is about actions that can be managed with operations
… the output value should be fetch later on

<kaz> describing the example withing the comment 23 hours ago

Ege: when we invoke something with input we get an output but it is explained how this is related to the new operations
… it is really underspecified

<kaz> referring to section 5.3.1.4 ActionAffordance

Ege: we must state that output is related to invokeaction and the output of queryaction is different

Cristiano: I agree that invokeaction and output must be connected
… we could add even a new field just for queryaction

Ege: right

Daniel: how can we use one model or another?

koster: a state machine description might help

Kaz: I agree, but we can defer this topic for the 2.0

Ege: I would like to postpone too
… and the keyword are there
… with the state machine we can clarify if you can query before invoking and what happens in different cases

Cristiano: I agree that it was a bit pre matured to introduce this new keywords
… is there any implementation beside webthings?

Ege: profile supports dynamic action instances

Cristiano: ok. I think profile spec is not really an implementation

McCool: right, we need to implement profile and understand if it is doable

<kaz> WoT Profile - 6.3.2.1.3 Asynchronous Action Response

McCool: webthing may be an implementation

Ege: but they will use out-of-band information
… is this really a valid implementation?

McCool: right, they need to align
… plus I agree with the point above that we should just allow one mode and not mix the twos
… moreover profile should just restrict TD features

Ege: right now we can't support this
… we don't have time
… the problem with TD is that every operation is atomic
… here we have relations between operations

McCool: maybe profile can specify orders between operations

Daniel: from the scripting api point of view, it is still difficult because the runtime can't know what to do
… just simply from watching the TD

McCool: I guess we agree that the spec is under specified

Cristiano: I think we could still support the trivial use case
… no dynamic ids

Daniel: yeah but we are not compliant with profiles

Ege: well the application can implement the profile logic

Kaz: I tend to agree to what as been said, technically profile should just define a subset of TD features for "out of box interoperability". TD itself does not really support dynamic IDs
… this is already wrong
… editors should keep an eye on this kind of consistency problems
… we should start from TD

Ege: yeah they were added to Profile first, but we can re-start the process now
… there are other implications but I skip them for now

issue 1276

<kaz> Issue 1276 - New TD 1.1 namespace IRI

Ege: this issue has the propose closing label
… we already solved
… with a pr
… I'm closing this, any objections?
… closed

Issue 942

<kaz> Issue 942 - Example 35 is incorrect or has inconsistency

Ege: same as above, any objections?(?
… closed

Issue 1139

<kaz>Issue 1139 - Creating subsections for readability

Ege: same, as above any, objections?
… closed

Issue 1202

<kaz> Issue 1202 - unit for human-redable / display purposes or as semantic annotation?

Ege: not really closed, but PR adds a note
… there still minor issues but we can solve them later
… closed

Issue 956

<kaz> Issue 956 - JSON Schema validation issue wr.t. "format": "iri-reference"

Ege: long standing issue, ajv not really support iri-reference

Ege: I would remove format
… for playground we implement validation
… there still some bit of validation happining

Daniel: I would prefer to remove it
… it causes too many issues
… easy fix

Cristiano: it seems that ajv now supports it?

Ege: not really

Cristiano: I see not a big deal to remove the validation then

binding templates

Ege: we have a few PRs

PR 151

<kaz> wot-binding-templates PR 151 - Improve MODBUS document

Ege: I did a review
… there are small typos
… it adds an abstract

Cristiano: can you check the default values? I am not sure they are 100% correct

Ege: I will ask around

PR 150

<kaz> wot-binding-templates PR 150 - Add pre-commit hook for rendering documentation

Ege: I like that this pr force people to run render before sending a PR

<dape> +1

Ege: ok. I'll merge this because it seems a valuable additions

PR 149

<kaz> wot-binding-templates PR 149 - CoAP Binding based on features

Ege: there's a long discussion on the PR
… jan gave a feedback
… the main concern that I have is that the changes were on the index.html but not in the template

Jan: I facilitate the discussion some aspects can be moved in an issue
… some aspects are more generic

Ege: moving the discussion to issues might be problematic because the PR will evolve

TD issues (revisited)

Issue 1407

<kaz> wot-thing-description Issue 1407 - Alternative composition mechanism for Thing Models

Jan: I worked on a converted for TD and SDF
… SDF support nested items
… when you translate that to a TD
… you need always to write them on the system to keep the structure consistent with links
… a solution might be a filed where you can nest other tms
… when create TDs you can resolve this models

Ege: follow the links limit the visibility
… I like the approach
… converting from DITTO to TMs might be another use case
… Imho we can go with your solution
… but you might have maintance problems

Jan: yeah
… maybe this can just cover one use case, you can still use links

Ege: so is this an alternative

Cristiano: I like the approach but it might be problems when you mix with links and try to generate TDs we have to clarify that

Ege: adjourned

<kaz> [adjourned]