Page Comparison

ATTENDEES: Wendy, Jon, Larry, Dan S., Jeremy, Johan, Guillaume, Kelly

DDI 4:
We're supposed to get most of content by NADDI
RDF may be delayed
--binding
--documentation (RDF specific)
--examples
--documentation of process
Earlier consensus of AG:
--Model itself
--serializations (XMI, XML, RDF)

TC has some role for input on the serializations and can be reviewed prior to transfer of content to TC
Get model serializations out for TC to look at prior to this

Criteria:
--Is the XMI just out there or does it have a purpose
--How is it to be used in the reveiw and can this XMI support that review - what systems are supported
(ex: caviates regarding mangling of cardinality and directionality of relationships in EA)
--Are these acceptable or unacceptable caviates.

XML - usages of the two sorts of XML the Library and the Views
What are the relationships?
Are they doing what we expect them to do - act as a profile or subset?
Do the serializations to what they say on the "tin"

RDF -
What is the minimum level we are willing to put out for review
Valid according to the spec and opens in Protégé - needed for review
This should be an iterative process - need to review
They need to use JIRA so we can see their progress
First call was last week, Second call today
First task is to formulate invitation language to send out within the week
Kelly will bring this forward to Eric

Highlevel documentation is the next essential about the relationship between the serialization and the model. What is the production system doing so that people can navigate between the RDF and the Model.

Round-tripability:
Something that needs to step up a bit in the review - Something that TC should be looking at and commenting on the problems/issues
Should take a look at what round-tripping means in reports from Dagstuhl 2017
Is there a clue to where the platform specific model vary from PIM in each case
There is the programming that makes the binding as one point
The model shouldn't be flattened for the RDF is a comment from last weeks RDF meeting.
Round trip means Binding to Model to Binding

DDI Lifecycle 3.3

COGS is now taking highlevel documentation and examples
It will be ready for dumping in more into it next week

(next week)
3524 - gt it in
3585 in is and needs review
(in progress - hopefully next week or 2)
Copenhagen mappings
COGS is not yet making the high level documentation for 3.3 so that needs to be worked on -

(will start on once the near final review version is ready - not a lot of time - task that needs to be done)
Do DDItoCOGS for 3.3 so we can test that out
Can use the strongly typed sheet from 3.2 plus the change log to identify what changes need to be made
Should Jon start uploading stuff into GITHUB or wait until Dan S. done some magic
Create branch for 3.2 first

(1-2 months)
High level documentation
All will be done in restructured text

2018 -
This year having the week long TC meeting was highly successful - bring up doing again in 2018

With controlled vocabularies have the DDI publish as DDI CodeLists - as well as current and proposed.

ATTENDING: Wendy, Oliver, Jon, Guillaume, Jeremy, Dan S.

DDILIFE-3524 need examples see issue
DDILIFE-3583 closed
DDILIFE-3584 closed

Documentation: Jon needs and hour with Jeremy next week to sort out final issues. Wendy needs to do a content dump for Jon.

Short Sprint prior to NADDI. This is at the pass-off point between documentation and TC review. This is being looked at as a chance to do the following:

Wrap up any documentation issues
Organize and plan work of TC review
Layout DDI4 project work for the remainder of year (this would include Drupal to COGS conversion of work platform)
[space has been arranged]

Oliver - remotely
Jon - remotely
Jeremy - maybe (Sunday is easter) focus is 3.3 almost certainly no

Announcement of sprints and ask people to participate

Should this be a TC meeting? in which case we have 3.3 work that could be done even if it is out for review. Implementation issues, software development issues.

We used to have annual face-to-face meeting and these have always been very productive we need to reinstitute support for this. If we want a TC meeting do we do this as part of a review of 4 or do we want more 3.3 line.

ATTENDEES: Wendy, Dan S., Jeremy, Oliver, Guillaume, Larry

DDILIFE-3524
Original idea was that the conditional text was interleafed with the static text. By using the current conditional text is compute text or identify text using the source parameter. But people want an IF condition that if something is true then insert this text. It's supposed to be generating the text but there is nothing there that does this. If we want both computing text and an IF statement that results in a literal text.

The conditional text type inserts a block of text
How can we a conditional for literal text choices - Using the control construct within the text is overkill so we could probably make something more streamlined for this situation.

IfStatement condition and text if true - should probably go through Else to provide a default insert at minimum

Resolve to add an IfThenElse to choice in ConditionalText.

WT will draft IfElse for dynamic text.

How to indicate the position. Write documentation and examples of usage.
Still want allow source parameter
Want to be able to insert a combination of a text and source parameter as a result of an IF - Limit to a combination of literal text and source parameter

Reviewed DDI_L_3 entries and pulled into Master

ATTENDEES: Wendy, Oliver, Johan, Jeremy, Larry

DDILIFE 3581 - OK to remove

DDILIFE 3582 all approved with following not#4. Make sure it stays in the same order as previous when it was in in AbstraceVersionable. If not just add to each (non Abstract) to retain order

#7-9 move to reusable

DDILIFE 3524 - Check with Guilaume and others about using computation and logical expression, separating "true" and "false" responses into separate conditinal texts. How to specify which text. Definately good to be able to express specific text insert in a consistent way.