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] URI and derefURI


On Jun 7, 2005, at 6/7/05 11:12 PM, Renato Iannella wrote:
> Q1: Do we need the relative URI at all?

Yes... this is a requirement for several folks building datacast  
applications where they to know where to place the dereferenced file  
within a larger filesystem at the receiving end, which will relative  
to wherever the receiver application happens to have rooted that  
received-data space.

The alternative was to introduce yet another element to contain the  
relative location of the contents of <derefUri> (suggestions for a  
better name would be warmly received here!)

An underlying assumption was that the absolute (network) and relative  
(broadcast) forms would never occur in a single message.  That came  
from a compromise we hammered out early on to mitigate fears of jumbo  
<derefUri> components clogging narrow channels (cf. the precise  
working in the CAP spec.)

(Personally, I think that bandwidth issue is one that can and should  
be addressed by the networks that have it rather than by hobbling the  
standard... but sometimes a compromise is the best one can achieve.)

So yes, it seems like we do need the relative URI, but my mind is  
open as to whether it should have its own element associated with the  
presence of a <derefUri>.

- Art



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