Content Packaging Meeting 2010-04-30
Jump to navigation
Jump to search
Notes from 'Content Packaging' Workgroup
Status of Notes: DRAFT
Date: April 30, 2010
Time: 1pm-2pm
Attendees: Honora Burnett, Arien Malec, Tim McNeil, Lin Wan, Matt Potter, Marc Stine & team, Eric Heflin, Vasu Manjrekar, Vidit Saxena, Vassil Peytchev, David Kibbe & David McCallie
Actions for This Week
Notes
Agenda and Framing
· Review of last week’s action items
· Discussion
· Next Steps
Discussion
· Summarize what we’ve agreed on for the meeting
· Agreed upon: message content will follow internet format standard and leverage Multipart MIME and we should have at least on canonical way of adding on the XDS metadata
o Resource representation would be a content type RFC/a22
o Can we get agreement on internet message format on minimal content message format
o We will put a straw man out there, try it and then if it doesn’t make sense we will revisit it
Vassil’s Concerns
· Edge has to expose content in a MIME format
· Universality, any HISP should be able to talk to any other HISP without a content negotiation
· HISPs need to speak a well defined standards protocol
· Internet message format using MIME to imbed the format with an * saying – we might have to redo this if it doesn’t work well
· IHE profile model? We’d have to adjust everything to fit this … different
· XDR route as backbone would drop MIME
· Available in the edge as vs. available in the middle yet
Rephrasing Proposal by Arien
· WE can decide to chose XDR as a backbone – can go through source to destination as a HISP and we don’t have to worry about internet form
· Also stated that we want at least one for polling mechanism and internet messaging gives us a good method for this
· Solving this: it is XDR in the middle, and map-able to internet messaging on the edge
· Signed message, trivial way of packaging as XDR and distributing
· Open for IHE implementation to come back and say “know you started with internet message format, but here is a clearer way to do that” or say “XDR is transport in the middle and here is the representation and here is how we are going to do it”
Round on shouldn’t hamstring the HIE Implementation Groups Hands
Comment from Lin Wan
· Shouldn’t tie groups hands
Comment from Eric Heflin
· Flexibility is the enemy of interoperability
· Provide a single guidance to other groups
Comment from Vassil Peytchev
· We want just one backbone protocol, but reserve the option of flexibility at the edges
Comment from David
· Focus on the MIME
· Mixed – core MIME
· Related – represent hierarchical dependence tree in the MIME itself
· XDM Wrapper
· Making related an unnecessary type
Arien will reframe problem
· Multipart MIME tells you what type your document is, but it doesn’t do much outside of that
· Sniff content to discover more about it
· Hard to two types of documents
· MIME doesn’t help there
· Minimal set of metadata and packaging it that allows the HER to do additional automate to support this work
· Wiki thread: is there a smaller subset of required fields that we can specify for these transactions?
If we want to send healthcare data that has non-trivial relationships should we just use XDM
Multipart MIME gives you minimal set of metadata, if you need more than multipart MIME the solution is to attach ZIP File with XDS Metadata
Comment from Mark Stine
· Both seem logical
· XDM seems more simple
Comment from Eric Heflin
· Single approach and single message – all cases it is XDM rather than having
· MIME/XDM
XDM makes sense over multipart related MIME
1) Package that we get in internet format that may contain XDS
2) Package that you receive may be an internet message format and that will be an XDM
· Reason why staying with simple is important: if it must be XDM, then you’re making easy things hard
· Quasi consensus XDM makes sense over multipart related MIME
· Alternative: optional MIME Type Receiver decide which encoding they can
· Choices:
o Strongly discourage the use of alternative
o Use only text if you intend to send text
o How constrained to we want to make this for the textual part of these messages
§ Text + HTML
§ Rich Text
§ PDF
o Tim McNeil: PDF
o Mark Stine: flexibility
o Eric Heflin: Is there a use case that would require/imply/result in an additional value for content being provided for something other than plain text? No.
o Vassil: prefer plain text
Consensus: Specify internet message format and it will be formatted by an email client that will be formatted by something that another email client does
Next time: Some point in the process – work though some details of the core use cases that we think will have in common – Text Corpus!
Status of Notes: DRAFT
Date: April 30, 2010
Time: 1pm-2pm
Attendees: Honora Burnett, Arien Malec, Tim McNeil, Lin Wan, Matt Potter, Marc Stine & team, Eric Heflin, Vasu Manjrekar, Vidit Saxena, Vassil Peytchev, David Kibbe & David McCallie
Actions for This Week
| # |
Date |
Action |
Status |
Owner |
Due Date |
| 14 |
4/21/10 |
Arien will revise spec to address the consensus |
Open |
Arien |
4/28/10 |
| 15 |
4/21/10 |
Call for consensus between now and the face-to-face: [1] |
Open |
All |
4/28/10 |
| 16 |
4/21/10 |
Create a discussion thread asking what everyone envisions as the common things to send for the text corpus. This will also point to User Stories |
Open |
David |
4/28/10 |
Actions from Last Week
| # |
Date |
Action |
Status |
Owner |
Due Date |
| 12 |
4/21/10 |
Arien will write a Requirements Document for Content Packaging Specification |
Open |
Arien |
4/28/10 |
| 13 |
4/21/10 |
Vassil will provide a “layering discussion on the Wiki |
Open |
Vassil |
4/28/10 |
Agenda and Framing
· Review of last week’s action items
· Discussion
· Next Steps
Discussion
· Summarize what we’ve agreed on for the meeting
· Agreed upon: message content will follow internet format standard and leverage Multipart MIME and we should have at least on canonical way of adding on the XDS metadata
o Resource representation would be a content type RFC/a22
o Can we get agreement on internet message format on minimal content message format
o We will put a straw man out there, try it and then if it doesn’t make sense we will revisit it
Vassil’s Concerns
· Edge has to expose content in a MIME format
· Universality, any HISP should be able to talk to any other HISP without a content negotiation
· HISPs need to speak a well defined standards protocol
· Internet message format using MIME to imbed the format with an * saying – we might have to redo this if it doesn’t work well
· IHE profile model? We’d have to adjust everything to fit this … different
· XDR route as backbone would drop MIME
· Available in the edge as vs. available in the middle yet
Rephrasing Proposal by Arien
· WE can decide to chose XDR as a backbone – can go through source to destination as a HISP and we don’t have to worry about internet form
· Also stated that we want at least one for polling mechanism and internet messaging gives us a good method for this
· Solving this: it is XDR in the middle, and map-able to internet messaging on the edge
· Signed message, trivial way of packaging as XDR and distributing
· Open for IHE implementation to come back and say “know you started with internet message format, but here is a clearer way to do that” or say “XDR is transport in the middle and here is the representation and here is how we are going to do it”
Round on shouldn’t hamstring the HIE Implementation Groups Hands
Comment from Lin Wan
· Shouldn’t tie groups hands
Comment from Eric Heflin
· Flexibility is the enemy of interoperability
· Provide a single guidance to other groups
Comment from Vassil Peytchev
· We want just one backbone protocol, but reserve the option of flexibility at the edges
Comment from David
· Focus on the MIME
· Mixed – core MIME
· Related – represent hierarchical dependence tree in the MIME itself
· XDM Wrapper
· Making related an unnecessary type
Arien will reframe problem
· Multipart MIME tells you what type your document is, but it doesn’t do much outside of that
· Sniff content to discover more about it
· Hard to two types of documents
· MIME doesn’t help there
· Minimal set of metadata and packaging it that allows the HER to do additional automate to support this work
· Wiki thread: is there a smaller subset of required fields that we can specify for these transactions?
If we want to send healthcare data that has non-trivial relationships should we just use XDM
Multipart MIME gives you minimal set of metadata, if you need more than multipart MIME the solution is to attach ZIP File with XDS Metadata
Comment from Mark Stine
· Both seem logical
· XDM seems more simple
Comment from Eric Heflin
· Single approach and single message – all cases it is XDM rather than having
· MIME/XDM
XDM makes sense over multipart related MIME
1) Package that we get in internet format that may contain XDS
2) Package that you receive may be an internet message format and that will be an XDM
· Reason why staying with simple is important: if it must be XDM, then you’re making easy things hard
· Quasi consensus XDM makes sense over multipart related MIME
· Alternative: optional MIME Type Receiver decide which encoding they can
· Choices:
o Strongly discourage the use of alternative
o Use only text if you intend to send text
o How constrained to we want to make this for the textual part of these messages
§ Text + HTML
§ Rich Text
o Tim McNeil: PDF
o Mark Stine: flexibility
o Eric Heflin: Is there a use case that would require/imply/result in an additional value for content being provided for something other than plain text? No.
o Vassil: prefer plain text
Consensus: Specify internet message format and it will be formatted by an email client that will be formatted by something that another email client does
Next time: Some point in the process – work though some details of the core use cases that we think will have in common – Text Corpus!