raw chat trace of meeting #201 on 2018-JAN-08

["Mr. Stefan Hagen" <stefan@hagen.link>]

[18:01] Stefan Hagen: Welcome to DSS-X Conference Call #201 - Monday, 08 January 2018, 06:00pm to 07:00pm CET
[18:01] Stefan Hagen: 1. Welcome by the chair (Stefan Hagen)

2. Minutes taker
All write into the chat, Stefan assembles and uploads into document area.
[18:01] Stefan Hagen: 3. Roll call
[18:01] Stefan Hagen: We are quorate: AK, EJvN and SH on the call
[18:01] Stefan Hagen: 4. Approval of the agenda
[18:02] Stefan Hagen: Agenda approved unchanged as published
[18:02] Stefan Hagen: DH joined
[18:02] Stefan Hagen: 5. Approval of minutes from previous calls
5.1 Minutes from call #200 on 2017-12-11:
URL = https://www.oasis-open.org/committees/download.php/62199/chat_trace_kavi.txt
[18:03] Stefan Hagen: Minutes approved unchanged as published
[18:03] Stefan Hagen: 6. Roadmap for 2018
[18:06] Stefan Hagen: Stefan suggests to put up a roadmap draft aligned to the already ongoing work and target dates via email - and the group will then discuss and eventually approve
[18:06] Stefan Hagen: All agree
[18:06] Stefan Hagen: 7. Core v2.0 issues discussion
7.1 Split of core schema in gateway/server and only-server
[18:06] anonymous morphed into Detlef
[18:08] Stefan Hagen: AK states, that the preservation service provided by DH and the chipboard gateway profile also do not require server side details and will profit from the split
[18:09] Stefan Hagen: DH brings to the table the question what exactly are the regions where a profile cannot enter, i.e. will profiles be allowed to combine other profiles et.
[18:10] Stefan Hagen: DH thinks the separation is fine plus minus some details
[18:11] Stefan Hagen: EJvN strongly suggests to first talk about the split, and then tackle more general questions like the rules for profiles etc.
[18:12] Stefan Hagen: AK shortly states the rationale for the split and specific distribution realised in the current revision
[18:12] Stefan Hagen: AK understands, that we create a universal schema without details to verification and signing and on top specialised schema part for verification and signing
[18:13] Stefan Hagen: All agree to add explanation and rationale to the documentation i.e. prose workproduct
[18:17] Stefan Hagen: 7.2 Editorial topics
7.2.1 Drop of ‘xs:any’ in the DSS-X specs for good or keep it as an option for XML syntax?
[18:18] Stefan Hagen: DH is not sure, if we can drop it, as handling optional input or output might require it for XML
[18:19] Stefan Hagen: DH: Question is how do we want to handle the specialisation required in implementing?
[18:19] Stefan Hagen: AK: Thinks the spec should decide about types, and not shift via xsd:any to a guessing implementation
[18:20] Stefan Hagen: DH: But what with combining two schemas?
[18:20] Stefan Hagen: AK: Suggests redefine to extend or restrict the type of optional in/output for simple cases
[18:20] Stefan Hagen: AK: For tricky cases, XSLT might be required
[18:21] Stefan Hagen: EJvN: Mentions namespace problems
[18:21] Stefan Hagen: EJvN: sees that there is always away around xsd:any which might be not very elegant, but it works
[18:22] Stefan Hagen: AK: Difference of schema from endpoint vs. schema from OASIS website /  repository
[18:22] Stefan Hagen: EJvN: Mentions, that implementers simply rewrite schemas just to avoid psd:any (just to be more type safe)
[18:24] Stefan Hagen: SH: Would be willing to drop and like in a spike, try how far this carries, or if there are the mentioned roadblocks ahead in combination corner cases
[18:25] Stefan Hagen: DH: Is not yet sure, to have understood the suggested workaround to replace psd:any
[18:25] Stefan Hagen: All discuss
[18:28] Stefan Hagen: AK: Suggests to describe the general solution to get rid of psd:any by use of XSLT and describe it in the prose document
[18:28] Stefan Hagen: Stefan is in favour of this
[18:28] Stefan Hagen: EJvN is also in favour of this (to give it a try)
[18:30] Stefan Hagen: AK will provide some documentation for the members so we can all actively try out the approach
[18:31] Stefan Hagen: AK mentions 2 general uses of xsd:any that we cannot work around by the strategy but maybe by using base64
[18:32] Stefan Hagen: DH suggests to agree on the right layer for extension points - i.e. where they specifically should be open and where fixed
[18:33] Stefan Hagen: AK: Maybe structure this and invent a new container element like done in the verification profile?
[18:33] Stefan Hagen: AK: Only one element added, but internally a huge tree
[18:34] Stefan Hagen: DH would like to discuss the case of one or more optional inputs and a profile
[18:34] Stefan Hagen: EJvN: But usually the profile adds the newly needed elements and add them to the optional inputs and outputs if necessary
[18:35] Stefan Hagen: All discuss what the intention of optional inputs and outputs defined in core and offered to profiles is
[18:36] Stefan Hagen: DH shows a diagram of the modular dss schema family and all discuss relation of profiles, core, and extensions.
[18:39] Stefan Hagen: All discuss HTOAS vs. WSDL
[18:39] Stefan Hagen: i.e. REST vs. WSDL/XML
[18:41] Stefan Hagen: EJvN suggests we produce a worked out example with some elements and show side by side old monolithic and new modular posture
[18:42] Stefan Hagen: Detlef shows some collapsed tree view on the schema landscape
[18:42] Stefan Hagen: DH proposals to remove optional elements from core
[18:44] Stefan Hagen: EJvN reminds that there are two kinds of usage of optional elements (1) in core maybe somewhat strange (2) profiles might require additional elements, and thus one wants to add those, and usually these are enabled by the optional elements from core. These are not intended to be used in full, but every profile can use a subset to extend the core in the profile domain
[18:44] Stefan Hagen: All discuss
[18:45] Stefan Hagen: All agree that profiles should be combinable
[18:45] Stefan Hagen: i.e. schemas composable
[18:47] Stefan Hagen: EJvN reports on typical tasks where schemas are to be combined for information exchange, mostly very big schemas with all elements optional and then specifications that select the required element sets for certain circumstances
[18:49] Stefan Hagen: DH suggests the server has to publish what are the retired elements not the core schema
[18:50] Stefan Hagen: SH and EJvN are sceptical if this is an adequate posture / distribution of responsibility (specification time vs. runtime)
[18:51] Stefan Hagen: EJvN agrees, that we have to find a solution like: Is element A and B supported, or even required ...
[18:52] Stefan Hagen: ... this can become complicated esp. when depending on values (not only on value independent inter-element rules)
[18:54] Stefan Hagen: EJvN suggests to maybe implement this announcement channel as an element which is outside of optional elements and thus can be used with long lists during runtime / information exchange to publish machine readable capabilities and rules of the server
[18:54] Stefan Hagen: Sections 7.2.2, 7.2.3 and 8 skipped due to time passed
[18:55] Stefan Hagen: Discussion will continue next meeting 
[18:56] Stefan Hagen: AK sees problems on implementation side how to evaluate the "list" info esp. on the client side
[18:56] Stefan Hagen: 9. Next meeting
Suggested to meet again on 2018-JAN-22 (usual bi-weekly schedule but skipping christmas)
[18:57] Stefan Hagen: DH will not available, EJvN also not available
[18:59] Stefan Hagen: There will be an informal meeting to prepare the groups decision process on these topics next week, and the next formal meeting will be on 2018-JAN-29
[18:59] Stefan Hagen: 10. AOB
[19:00] Stefan Hagen: None
[19:00] Stefan Hagen: Meeting adjourned