On 26.Aug.2003 -- 06:33 PM, Stefano Mazzocchi wrote: > > On Monday, Aug 25, 2003, at 11:12 Europe/Rome, Christian Haul wrote: > > >On 17.Aug.2003 -- 07:00 PM, Stefano Mazzocchi wrote: > >> > >>Issues that were still unsolved > >> > >> > >> > >>1) block identification > >> > >>All blocks (behaviors and implementations) are identified by a URI. > >>the > >>format of the URI is as follows: > >> > >> cob:organization/name/x.y(.z) > > > >If we would identify a block by an XML document instead of a URI, we > >could list features of a block. Version numbers are a very poor tool > >to match requirements and capabilities. > > nonono, you are making the usual URL vs URI mistake: we want to > *identify* a block (either its implementation or its behavior). The > location service (that is also, metadata discovery about that block) is > an entirely separate issue and *MUST* remain the same in order to allow > a high level of decoupling between a resource and the actual location > of where those resources are.
IOW there is no need to force a naming scheme. So why should we? Anyway, this was intended for the discussion of > >> 2) dependency ranges and I'm glad that you see this problem solved by the discovery service. However, I don't get why you need dependency ranges: > >>When a block implementation depends on another block (either > >>implementation or behavior), it should be able to have an 'elastic' > >>dependency which doesn't connect it to the versioned identifier, but > >>to > >>a range of those versions. Which is the whole point of my mail. Don't use dependency ranges, use metadata specifying capabilities and requirements for this. Chris. -- C h r i s t i a n H a u l [EMAIL PROTECTED] fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08