Re: AtomPub Multipart Open Issues

["Sylvain Hellegouarch" <sh@xxxxxxxxxx>]

>
> On Wed, Jul 2, 2008 at 1:47 PM, Sylvain Hellegouarch wrote:
>>
>>> On Wed, Jul 2, 2008 at 10:52 AM, Sylvain Hellegouarch wrote:
>>>>
>>>> I have to agree with Bill. "related" is only one use of the multipart
>>>> subtypes. Joe, rather than post-options="multipart", why not using
>>>> multipart="related|form-data|alternative|...".
>>>
>>> Except that not all multipart types don't have the notion of a "root
>>> part":
>>>  - multipart/form-data is likely to be used with parts such as
>>> "title", "summary", "summary-type", "content", "content-type",
>>> "author", etc. and even if an Atom Entry would be sent, there's no
>>> notion of a "root part"
>>>  - how would you use multipart/alternative? And you cannot reference
>>> one "alternative" from another using a cid: URI, it would be a
>>> multipart/related (eventually included as one of the "alternative"
>>> parts).
>>
>> I don't quite see how that precludes the use of the
>> multipart="related|form-data|alternative|..." style of attribute. Your
>> point is more about why and how AtomPub services should consider
>> choosing
>> and handling one of the subtype.
>
> Right, sorry, I misunderstood your point...
> However, it won't work as it precludes the use of multipart/related
> for things that aren't draft-gregorio-atompub-multipart -compatible
> ...or it makes them undistinguishable: ah OK, supports
> multipart/related, but is it supporting
> draft-gregorio-atompub-multipart? is it supporting CompoundEntries?
> http://intertwingly.net/wiki/pie/PaceCompoundEntries
>
> And it won't work also because "form-data" isn't specific enough:
> which "fields"? how are they named? (or maybe there should only be one
> non-file field, containing an Atom Entry, and referencing the attached
> resources using their file-name: <content src="EntryContent.html" />)
>
> But if you're only talking about the attribute's "style", then OK (see
> last line of this mail); you'd have to define it as NTOKENS though to
> allow things like multipart="alternative x-CompoundEntry"

I see your point. I think the multipart="..." attribute is just a way for
a AtomPub service to advertise it supports a given extension that
describes how the MIME subtype would be handled.

In other words multipart="form-data" would just be a way of saying "I
support ID XXXX" assuming the AtomPub community has created an ID
describing how form-data could be handled.

For instance multipart="related" would thus mean "I support
multipart/related as describe in ID (defined by Joe)".

In case of multipart="form-data", an ID could then introduce a new
attribute to handle the specifics of that subtype, e.g.
form-data-field="name" (I'm just making a gross example here).

Obviously there is a problem when more than one ID exist for a given
subtype because that attribute mechanism doesn't offer a way to
differentiate them.

Somehow we are back to the problem the WG had tried to tackle a few months
ago regarding "the formal way to advertise support for a given feature".

- Sylvain

-- 
Sylvain Hellegouarch
http://www.defuze.org