Scribe
- Martin Sarabura (PTC)
Attendees
- Jim Amsden (IBM)
- David Honey (IBM)
- Martin Sarabura (PTC)
- Ian Green (IBM)
- Jad El-khoury (KTH)
- Axel Reichwein (Koneksys)
Resolutions
Actions
- All TC members should review list of changes to core spec made by Jim
- Ian to raise issue re accepted literals
Chat transcript from room: oslc
[14:04] Martin Sarabura: Martin will scribe
[14:04] Martin Sarabura: https://wiki.oasis-open.org/oslc-core/Meetings/Telecon2018.04.05
[14:05] Martin Sarabura: Minutes accepted
[14:05] Martin Sarabura: Jim: Core specification updates
[14:06] Martin Sarabura: Should get them reviewed, submit for a new public review - update committee specification
[14:06] Martin Sarabura: Same email sent out a while ago, listed the issues
[14:08] Martin Sarabura: Jim will (re?)send the email
[14:09] Martin Sarabura: Action: All TC members should review the changes in time for next week
[14:10] Martin Sarabura: From Nick:<<BR>> My status/progress: I have started to work on text for the TRS spec, but I have not committed it yet. For more use of etags in TRS, recent internal discussions have led me to believe that we are premature with this
topic (there are too many cases where there could be false positives and false negatives from etag checking), and that we do not have a reasonable and implementable scheme to propose - so I recommend deferring (or just plain closing) the issue I raised on
that.
I have responded to Jad's RM review comments/questions.
I have not yet written the RFC for the Config Management header.
I have not yet had time to review the Core changes.
[14:11] Martin Sarabura: Ian sent message about why there is a fixed set of options for Literals
[14:12] Martin Sarabura: What do we do if we want to extend that list?
[14:12] Martin Sarabura: Core says: A datatype must be one of the following individuals:
[14:13] Martin Sarabura: Maybe done to make it easy to become compliant
[14:14] Martin Sarabura: Eg., int vs integer
[14:14] Martin Sarabura: Unpredictable which you will get; resulting differences may lead to accidental incompatibilities
[14:15] Martin Sarabura: David: Isn't it part of the xsd spec how to do conversion?
[14:16] Martin Sarabura: Helpful if all domains had same representation of a given type
[14:16] Martin Sarabura: Potential data loss/conversion issues
[14:17] Martin Sarabura: David: XSD:DateTime can accept with full string, abbreviated forms can be quite challenging
[14:18] Martin Sarabura: What about leaving the prescription to the point where you publish the domain? rather than in core?
[14:20] Martin Sarabura: Double-edged sword - additional flexibility on client makes it easier, but reduces certainty of data you have to deal with
[14:22] Martin Sarabura: Duration not specified - could invent a representation but it varies from implementation to implementation
[14:22] Martin Sarabura: Hard to infer from shape how exactly to interpret
[14:24] Martin Sarabura: Should we raise an issue?
[14:25] Martin Sarabura: RDF xml is unconstrained
[14:26] Martin Sarabura: Couldn't we just relax the spec to say SHOULD and indicate other acceptable namespaces such as XSD
[14:27] Martin Sarabura: OSLC API may become impoverished by being strict about the available representations
[14:28] Martin Sarabura: Ian: Partner or customer was complaining because Lyo didn't accept non-conformant literals
[14:29] Martin Sarabura: David: Maybe identify a few more that we actually care about
[14:30] Martin Sarabura: Meeting adjourned
Dr. Martin Sarabura
Technical Fellow, Office of Research & Architecture
+1 (519) 502-4819
msarabura@ptc.com
ptc.com