<kaz> scribenick: McCool

Publication BG

Lagally: in addition to the usual architecture discussion, would like to talk about the joint discussion with PBG

Kaz: planning to have joint meeting WoT/PubBG
... on Oct 13
... on wiki

<kaz> agenda wiki

McCool: noticed we only allocated 30m

<kaz> agenda issue

Daihei: 30 minutes out of 90m of a longer special meeting
... and there are actually two of these
... at noon Oct 13 Eastern for Europe
... another at 8pm Eastern time, for Asia
... and it would be good if WoT can attend both
... the Asian one is actually a Japanese session, so if Kaz can present in Japanese...
... also implies we want formal presentation material

Lagally: what should the outcome/goals be?

Kaz: determine possible use cases from publishing

McCool: so should we try to guess what aspects of WoT would be relevant?

Daihei: truth is very few people know about WoT, or even IoT
... so we need some basic information presented to publishing community
... and position it relative to other smart technologies
... for instance, smartphone is becoming a very important device, as opposed to dedicated ebook
... so an initiation is needed; "novice" presentation is needed

McCool: what use cases do you (dh) think make sense?

Daihei: audio books, for instance; overlap with media
... and may want to connect with home audio systems, etc.
... second screen
... ebooks, how content can be applied

Lagally: what kind of target devices... capturing in issue
... what about video devices? Is that Pub or MEIG?

Daihei: is part, e.g. educational, but not immediate, can leave to MEIG for now

<kaz> ka: technically video media and devices for that purpose is the overlapping area of the MEIG and the Publishing, we can ask the MEIG guys about their opinions but if there is any idea on the Publishing side, that's also welcome.

McCool: what about things like active notebooks?

Daihei: interesting, but not really happening... want to stimulate people to think about the opportunities
... to think about web content as part of the business
... also things like mathml

<kaz> (and possibly SSML for speech synthesis :)

Lagally: looking at the member companies... most are from print industries originally
... now transitioning to ebooks, but mostly static content

Daihei: right on the money, yes, 80-90% is based on print
... ebooks are faithful representation of print
... that is their mindset
... hard for them to imagine how web content will come in

Lagally: so you also requirements for accessibility, etc?

Daihei: yes

Kaz: w3c has had several workshops on advanced ebooks... including video, etc.

Lagally: so we need to define some crisp use cases...

Kaz:: right. and that's the purpose of this joint meeting on Oct 13 :)

Lagally: is there any pubbg documents we could review?

Daihei: recall we just want to have a general introduction
... then expectations of use cases

McCool: maybe the slides can be a joint effort
... we can do a basic intro, we can jointly brainstorm some use cases, then we together can fill in details

Lagally: note we do have a F2F next week, there is a use case call on Oct 7
... if we aim at the last 30m or so it will be 7:30am or so in Pacifici time

McCool: note that MEIG will also be there and some of the use cases overlap

<kaz> time table of WoT vF2F

McCool: eg AR, content management, media control/sync, etc.

Lagally: ok, I will see if I can shuffle the agenda a little bit to put the material Daihei may be interested in later

Kaz: have updated times and dates

<kaz> Pub BG collab agenda issue

McCool: do we have a link to the logistics?

Daihei: not allocated yet...

Kaz: then I can allocate and send them to you

McCool: zoom or webex?

Daihei: zoom probably better

Kaz: ok I will allocate that

<kaz> ACTION: kaz to allocate two zoom calls for PUB BG collab

McCool: think we need to do some content bashing; basic material from sebastian/ege/kaz, my summary, etc.

<kaz> (Daihei leaves)

Minutes review

<kaz> Sep-24

anyone have any concerns?

no, approved

Profile FPWD

Lagally: suggest we take what we have and publish a FPWD to encourage discussion

McCool: would be good to have editor's notes for things that need discussion

<kaz> PR 36 preview

Lagally: would rather keep it simple, and just take the current document and ask for input

McCool: agree that publishing is more important than polishing when it comes to FPWD

Lagally: although there is a PR with editorial fixes
... PR #36

<mlagally_> https://github.com/w3c/wot-profile/pull/36/files

Lagally: this pr removes some redundant material, fixes references, resolved respec errors
... want to propose that we merge this and ask for a 1wk review
... prefer announce today, ask for a review, get feedback next main call, then polish for resolution the week after that
... also input into the vF2F meeting on monday!

McCool: yeah, no actual main call next week...

Lagally: propose we merge these editorial fixes now

McCool: no objections

Lagally: merging...
... and of course we DO have respec errors
... will offline do another PR to fix those

Architecture FPWD

Lagally: don't have a PR yet, but did make a patch, creating...

<mlagally_> https://github.com/w3c/wot-architecture/pull/544/files

Lagally: includes removing Matthias from editors, including in acknowledgements, after talking with him

Sebastian: I guess I should do the same for the TD

Lagally: yes, but probably should talk to him first

McCool: probably should move Kajimoto-san to the acknowledgements to be consistent with former editors

Lagally: not sure if Kawaguchi is still able to work as editor, we should check
... ... ideally Panasonic will be able to nominate someone

Kaz: will be following up with them

Lagally: propose that we merge this version as the FPWD candidate, and also use this as the basis for input on Monday
... will ask for concrete input to make Monday as productive as possible
... want to merge PR 543; any objections?
... no objections, merging

<kaz> PR 543

Sebastian: but there are more PRs for architecture...

Lagally: PR 544 seems to showing diffs that are not real, closing without merging

<inserted> PR 541

McCool: PR 541 replaces "Thing Description Template" with "Thing Model" generally

Lagally: looks good, merging
... merged

<inserted> PR 528

Lagally: PR 528 from Farshid, deferred until we can talk to him

F2F agenda

<inserted> vF2F agenda

McCool: unfortunately, do have to limit to 3h
... already have to compress other things

Lagally: ok, let's add some details to the agenda
... starting with FPWD review

McCool: also need time for opening session, breaks
... wrapup; Lagally can do, should indicate followup actions
... I will do opening session

Lagally: link relation types...

McCool: need to consolidate from lots of places, at least point people at it

(above is actually a new topic, "requirements")

Lagally: still many pending requirements needed

McCool: would be good to decide where we are going to publish requirements, eg. so we can cite them from other documents

Lagally: need to review the process as well
... need to keep use cases open, separate informative use-cases document
... need to take requirements out of the "Use Cases and Requirements" document, cover them in architecture, have a formal WG process to adopt them

McCool: sure, TFs can review and make PRs against the Architecture document

Kaz: as mentioned in use case call, still think it would be easier to handle requirements as part of the "Use Cases and Requirements" document on the IG side
... but ok with publishing FPWD as is given the timeline

McCool: perfectly fine for IG to *propose* requirements, but I think WG should review, decide upon, and *publish* them

Lagally: and we could also add a "Requirements" section to use case template to facilitate that process
... (edits use case template)
... can be a high-level summary, requirements doc itself could go into more detail, with references, etc.
... in the use case template it can just capture high-level points

Kaz: note that requirements are technically informative...

Lagally: very important question, when do we want things to be normative?
... it's when we want to make sure people do things the same way, eg. for interoperability
... weak standards that allow many alternatives cause problems

Kaz: assertions need to be clear, and need implementation report, etc., for REC track documents

McCool: yes, want to avoid an unnecessary testing burden

Lagally: some things are hard to test... e.g. scalability requirements

McCool: rather than tests, we can just have implementers report they agree and support the assertions

Lagally: currently we don't use RFC2119 terms, we can discuss that later

<kaz> Mobile Web Best Practices

Kaz: should talk to W3M
... note there was a "mobile best practices" that provided informative content only plus implementation examples. however, that is a very old (12 years ago) example, so I'd suggest we consult with PLH again.

McCool: note that a REC is supposed to have normative content in it, so...
... but I personally would feel more comfortable having formal agreement from implementers on certain topics, e.g., privacy controls

OneDM/TM

Lagally: time is short, move to next week

Koster: ok, will upload presentation material, can review in the meantime

Thing Models

Lagally: sebastian, and additional use cases or requirements

Sebastian: current situtation in TD spec
... is not real section called "Thing Model"
... based on the definition we had before for Thing Description Template
... which was in the annex in the past, but we added a few details, like adding an @type to identify it
... and stuff like inheritance as a suggested use case/will be addressed
... we are definitely in the beginning
... there is also a PR
... TD PT #540

<inserted> PR 540

McCool: think also that should not use "peculiarity", just state how TD and TM differ
... and I think it's just that a TM may omit certain information

Lagally: also, "class" is not quite right; more of an "interface" than a "class"

McCool: probably just say "abstract class" for now

Lagally: "interfaces" in Java have been extended, and CORBA has some similar things

McCool: TDs are objects, and TMs are definitions of the "set of objects" which is literally what "class" is *supposed* to mean mathematically (class is just another word for "set")

Sebastian: more precise details are coming, TM is introduced in first draft

Lagally: yes, it would be nice to flesh out this section in FPWD in TD spec then... to get review feedback

Kaz: ok with merging PR, but technically should clarify what use case requires the feature, etc.

Lagally: where would you put this information?
... would cross-references really help?

Kaz: if we do add additional features, then we should clarify motivation. adding cross-references would be good.

McCool: I think we should have detailed cross-references between use cases and requirements, but after that the design can just state that is meets the requirements.
... by the way I think TM is motivated by the need for abstraction in the digital twin use case

AOB

Kaz: regarding normative/informative, will talk to Philippe and Ralph about what makes sense
... just want to head off criticism late in the process

<kaz> [adjourned]