Scribe
-
Nick Crossley (IBM)
Attendees
-
Andrew Berezovskyi (KTH)
-
Jim Amsden (IBM)
-
Martin Sarabura (PTC)
-
Nick Crossley (IBM)
-
Ian Green (IBM)
Resolutions
Actions
-
Jim to ask Chet to create new Git repository for ReSpec
-
Nick to investigate automatic conformance clause numbering
Chat transcript from room: oslc [14:06] Nick Crossley (IBM): Nick to scribe
[14:06] Martin Sarabura: https://wiki.oasis-open.org/oslc-core/Meetings/Telecon2018.06.07
[14:06] Martin Sarabura: https://wiki.oasis-open.org/oslc-core/Meetings/Telecon2018.06.14
[14:07] Nick Crossley (IBM): No objections received - both minutes are approved
[14:09] Nick Crossley (IBM): Jim announces: As of now, ReSpec generates publishable documents, with only one manual step (generating
PDF and adding footers).
[14:09] Nick Crossley (IBM): Jim: Thanks to Nick.
[14:09] Nick Crossley (IBM): Nick: But Jim did the recent work to bring ReSpec into full compliance!
[14:10] Nick Crossley (IBM): New ReSpec has updated dependencies, including the latest version of Node.js.
[14:11] Nick Crossley (IBM): Nick: But ReSpec source is still in Nick's personal Github, which is not sustainable long term
[14:12] Nick Crossley (IBM): Jim: We could move it to OSLC Domains GitHub, or OASIS gihub
[14:12] Nick Crossley (IBM): Andrew: OSLC one would allow us more control
[14:13] Nick Crossley (IBM): Jim: Our ReSpec is still a fork of the W3C ReSpec,
but at this point it has diverged quite a bit, and could be made entirely separate - but the effort involved is probably not worth it.
[14:13] Nick Crossley (IBM): Jim recommends moving it to OSLC Domains GitHub.
[14:15] Nick Crossley (IBM): Nick: Core tools (ReSpec and ShapeChecker)
should be handled in a common way.
[14:15] Nick Crossley (IBM): Jim: Cannot have two different source control mechanisms - but we could move Core entirely to GitHub.
[14:16] Nick Crossley (IBM): Jim: ask OASIS admins to create common OASIS GitHub repo for OSLC tools, move both ReSpec and ShapeChecker to
that, but keep Core itself in SVN so we do not lose history.
[14:17] Nick Crossley (IBM): Nick: No objection to this approach.
[14:19] Nick Crossley (IBM): Jim & Nick discussed how many GitHub/svn repos we need.
[14:20] Nick Crossley (IBM): Jim: Action Item: will talk to Chet about creating a new GitHub repo.
[14:21] Nick Crossley (IBM): Jim: would like to discuss conformance clauses.
[14:21] Nick Crossley (IBM): Jim: has fixed them for domain specs, and Chet has approved.
[14:22] Nick Crossley (IBM): Jim: domain specs already had a section with conformance clauses, and Jim just had to retitle that section and add numbers.
[14:23] Nick Crossley (IBM): Jim: believes For is not too far away - needs to add a new section to the 1st part of the multi-part spec, with short statements referencing the other parts of the spec.
[14:23] Nick Crossley (IBM): Core, not For.
[14:27] Nick Crossley (IBM): NIck: I have two concerns about the approaches used/proposed for OSLC, both about maintainability. One is that any numbered references cannot be manual - such references would get out of step too easily.
[14:28] Nick Crossley (IBM): The other is the an excess of copied & pasted text is also not maintainable.
[14:31] Nick Crossley (IBM): Nick & Jim: discussed how important the conformance statements are to a reader. Jim would prefer to minimize changes to the document to avoid the possibility of incompatible changes, rendering existing statements of use invalid.
[14:32] Nick Crossley (IBM): Jim: the above argument doesn't apply to Core 3.0, since that is different in structure, and sufficiently different from 2.0 already.
[14:32] Nick Crossley (IBM): Jim: Chet has agreed we do not need to automate the production of summary tables as that would be too much work.
[14:36] Nick Crossley (IBM): Nick: would prefer to have the conformance section content auto-generated by ReSpec to avoid
duplication of text or fixed numbered references. I have allocated some time next week to work on ReSpec to investigate/
implement this.
[14:36] Nick Crossley (IBM): Jim: Resource Shapes is the part of Core that would need most work to take advantage of any such work.
[14:37] Nick Crossley (IBM): Jim: suggests adding a style class='conformance-clause' - Nick agrees that is likely to be the best approach.
[14:39] Nick Crossley (IBM): Jim: will update Core, but not TRS.
[14:40] Nick Crossley (IBM): Jim: What about conformance clause numbers? Are they fixed or would they get renumbered as new sections or clauses were added?
[14:41] Nick Crossley (IBM): Nick: Previously discussed - W3C specs, for example, are just dynamically numbered, so yes, numbers will change over time.
[14:41] Nick Crossley (IBM): Nick: will report back to the TC next week on progress made on this topic.
[14:42] Nick Crossley (IBM): The above is an action item.
[14:42] Nick Crossley (IBM): Jim: will write introduction for this new section for Core.
[14:45] Nick Crossley (IBM): Nick: fallback is to proceed with the approach Jim is already using, and Nick to do something equivalent for TRS and Config Management.
[14:46] Nick Crossley (IBM): Query will also need its conformance clause section.
[14:47] Nick Crossley (IBM): Nick: David has a new role at the moment, and his time may be limited. We need to get him present for at least one subcommittee discussion, and then getting some help with editing that spec might be required.
[14:48] Nick Crossley (IBM): Jim: Agreed - but Jim has no bandwidth available to help with that.
[14:49] Nick Crossley (IBM): Nick: little progress on TRS this week.
[14:49] Nick Crossley (IBM): Andrew: would like to discuss GraphQL.
[14:50] Nick Crossley (IBM): Andrew: should not define or require any new query languages for OSLC, but would like to see if we can enable discovery of such capabilities.
[14:51] Nick Crossley (IBM): Jim: We are committed to OSLC Query for compatibility, and sees no need to add any other languages - doing so would only encourage fragmentation.
[14:53] Nick Crossley (IBM): Jim: I see no value in adding discovery of something not defined, not well known.
[14:54] Nick Crossley (IBM): Andrew: would like to support LDN. So would like to be able to add discovery info about this, and/or GraphQL.
[14:55] Nick Crossley (IBM): Jim: Do those other standards not describe discoverability? It should be up to those standards to define their own discovery.
[14:55] Nick Crossley (IBM): Jim: would strongly resist coupling specs by adding discovery in OSLC for non-OSLC standards.
[14:56] Nick Crossley (IBM): Martin: does not really agree with that opinion - we should be open to adding discovery of new and better services.
[14:57] Nick Crossley (IBM): Jim: but services are already perfectly capable of adding new discovery mechanisms for new capabilities - we cannot predict what they will want to do, and should not constrain that in any way by saying they have to fit into some
predefined OSLC discovery scheme.
[14:58] Nick Crossley (IBM): Jim: OSLC already says servers may implement other query schemes.
[14:58] Nick Crossley (IBM): Martin: but wouldn't it be more friendly if clients could ask 'what query capabilities exist?", and select the one they want to use.
[15:04] Nick Crossley (IBM): General discussion on service discovery and well-known URIs.
[15:04] ian green: Sorry gents, but I need to leave the call.
[15:04] Nick Crossley (IBM): Andrew: Can we get more of a spec on the jazz root services doc?
[15:04] Andrew Berezovskyi (KTH): https://issues.oasis-open.org/browse/OSLCCORE-9
[15:05] Andrew Berezovskyi (KTH): http://docs.oasis-open.org/oslc-core/oslc-core/v3.0/cs01/part2-discovery/oslc-core-v3.0-cs01-part2-discovery.html#bootstrappingDiscovery
[15:06] Nick Crossley (IBM): Nick: unlikely to get jazz root services doc standardized - third-party products do have to implement this for integration, but fundamentally that document is IBM-defined, not normal RDF.
[15:07] Nick Crossley (IBM): Nick: running out of time - meeting adjourned.
Dr. Martin Sarabura
Technical Fellow, Office of Research & Architecture
+1 (519) 502-4819
msarabura@ptc.com
ptc.com