RE: Sending e-mails from a pipeline...

The em:content tag isn't suited for RTF nor HTML indeed, but if you would
come up with an xml syntax of your own, I am sure one would be able to fit
it in nicely. Or just as a c:data if necessary. Content-id's could be
derived from base-uri's perhaps?

PS: all those various namespaces, looks just too silly to me. Why not a
c:message syntax of our own? Anyone using em/rf will just have to
transform it.. ;-)

-----Oorspronkelijk bericht-----
Van: Norman Walsh [mailto:ndw@nwalsh.com]
Verzonden: woensdag 16 november 2011 13:19
Aan: XProc Dev
Onderwerp: Re: Sending e-mails from a pipeline...

Geert Josten <geert.josten@dayon.nl> writes:
> Is MIME something a user needs to care about? (i.e. isn't that something
> that can be shielded from the user?)

If you make the simplifying assumption that you only care about plain
text or HTML, single part messages, then it's fairly easy (leaving the
underlying configuration that David mentioned off the table for the
moment.):

<cx:send-mail xmlns:em="URN:ietf:params:email-xml:"
              xmlns:rf="URN:ietf:params:rfc822:">
  <p:input port="source">
    <p:inline exclude-inline-prefixes="em rf cx">
      <em:Message>
        <rf:subject>Sample Plain Text Email</rf:subject>
        <rf:from>
          <em:Address>
            <em:name>Norman Walsh</em:name>
            <em:adrs>ndw@nwalsh.com</em:adrs>
          </em:Address>
        </rf:from>
        <rf:to>
          <em:Address>
            <em:adrs>ndw+mailtest@nwalsh.com</em:adrs>
          </em:Address>
          <em:Address>
            <em:name>Norman Walsh</em:name>
            <em:adrs>norman.walsh@marklogic.com</em:adrs>
          </em:Address>
        </rf:to>
        <em:content>Hello World</em:content>
      </em:Message>
    </p:inline>
  <p:input>
</cx:send-mail>

And Murray is right, maybe this is the 80/20 or even 90/10 case and we
could stop there. But the engineer in me can't resist at least
exploring 80-90 percent of the remaining 10-20 percent :-)

Consider this pipeline fragment:

<p:identity name="jpg">
  <p:input port="source">
    <p:data href="/Users/ndw/Documents/Graphics/Avatars/Avatar-16.jpg"/>
  </p:input>
</p:identity>

<p:identity name="log">
  <p:input port="source">
    <p:data href="/var/log/application/error.log"/>
  </p:input>
</p:identity>

<cx:send-mail xmlns:em="URN:ietf:params:email-xml:"
              xmlns:rf="URN:ietf:params:rfc822:">
  <p:input port="source">
    <p:inline exclude-inline-prefixes="em rf cx">
      <em:Message>
        <rf:subject>Process failure</rf:subject>
        <rf:from>...</rf:from>
        <rf:to>...</rf:to>
        <em:content>Alert:
Processing this image caused an error in operations.</em:content>
      </em:Message>
    </p:inline>
    <p:pipe step="jpg" port="result"/>
    <p:pipe step="log" port="result"/>
  </p:input>
</cx:send-mail>

That's supposed to send the text email with two attachments.
Unfortunately,
the mail infrastructure needs to know (at least) the content-type and
content-disposition of each of the attachments.

Maybe 80-90 percent of the remaining 10-20 percent is simply to make a
best guess at the content type and send them as attachments. In this
case, that works out ok. Probably. The c:data element for the image
will include the content-type image/jpeg so that'll be ok. The log
file might or might not have a content-type, but if it doesn't
application/octet-stream is a plausible default.

If we wanted to go even further, I think we'd have to do content
inspection and transformation that I think is firmly in the last few
percent. (I'm thinking of the case where an HTML message is sent that
contains an img element; if you want the mail client to display the
image inline, you have to use content-id and do other things that must
be described in some spec I've never read.)

                                        Be seeing you,
                                          norm

-- 
Norman Walsh
Lead Engineer
MarkLogic Corporation
Phone: +1 413 624 6676
www.marklogic.com

Received on Wednesday, 16 November 2011 12:35:33 UTC