<kaz> scribenick: McCool
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)
<kaz> Sep-24
anyone have any concerns?
no, approved
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
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
<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
Lagally: time is short, move to next week
Koster: ok, will upload presentation material, can review in the meantime
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
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]