OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [emergency] W3 Releases Packaging Recommendations

Yes, the XOP core recommendation appears, by my reading, to start 
with the assumption of infosets that include base-64 encoded elements 
(such as <derefUri>) and provides a mechanism for transmitting the 
binary data in its more concise, unencoded form by converting the 
whole XML document into a multipart MIME package with the XML in one 
section and the binary data in another.

It seems like this will be useful in those few one-way transport 
contexts where the inclusion of <derefUri> data is appropriate... but 
it doesn't strike me as any re-invention of <derefUri> or anything 
that conflicts with the current CAP formulation.  It's just a more 
efficient transmission scheme for a common kind of element of which 
<derefUri> is an instance.

Anyway, it'll take some time for that to roll out into the 
environment and it seems like we have more immediate concerns for CAP 
1.1 than revisiting the <derefUri> debate.

Bob, in our coda to last week's call I thought I heard you suggest 
there might be a clean way to provide for the incorporation of 
external-namespaced elements within <resource> in the CAP 1.1 schema. 
Have you had any luck developing a specific proposal for that?  I 
imagine the TC will need to set some sort of cutoff date for new 
issues for 1.1 in the near future.

- Art

At 10:10 PM -0500 1/30/05, Bob Wyman wrote:
>CAP V1.1 provides a mechanism for including "de-referenced" objects 
>within resource elements. (ie: derefurui)
>W3C has just released a set of recommendations that address similar 
>concerns in the context of Web Services. It would probably make 
>sense to study these recommendations to see if there are any ideas 
>that can be incorporated or if their mechanisms are preferable to 
>those currently in the V1.1 draft. As always, it is a good idea to 
>avoid too much "invention" when creating standards that are intended 
>to be used widely. Doing things using methods with which developers 
>are already familiar tends to increase the likelihood of 
>See the W3C press release, with links to the three new recommendations, at:
>                         bob wyman

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]