RE: [widgets] Widgets URI scheme

I'm still disturbed by an interoperability problem if there are alternative ways of expressing the same path where not all implementations can read and processs all of the expressions.

The URI decoder is separate from the zip software, so its reasonable to use UTF8 everywhere.

This is very related to the issues with the file: scheme that I've started looking at again.

 -----Original Message-----
From: 	Jon Ferraiolo []
Sent:	Wednesday, May 28, 2008 03:25 PM Pacific Standard Time
To:	Larry Masinter
Cc:	'Marcos Caceres';;;
Subject:	RE: [widgets] Widgets URI scheme

Hi Larry,
Comment ša va?

While I understand the strong preference for referencing real specifications from real standards bodies, in the particular case of ZIP, there are already a few cases where leading industry formats felt it was OK to reference the PKWare site. Marcos's blog entry ( provides links to the specs for JAR, ODF, OOXML/OPC, and OEBPS, all of which reference the PKWare app note. It is certainly true that the ZIP spec is subject to change at the whims of a particular company; therefore, the key thing is to make sure that your own spec clearly defines which particular set of features from the ZIP app note are required. 


"Larry Masinter" <>

				"Larry Masinter" <> 
				Sent by: 

				05/28/08 03:06 PM


"'Marcos Caceres'" <>	

<>, <>	

RE: [widgets] Widgets URI scheme	

One set of questions the current specification raises are similar to the
ones that were raised during discussions of registering a zip-based MIME
type: that the referenced ZIP specification itself is not a standard,
implementations vary, and that a simple reference to the PKWare "ZIP"
specification wasn't sufficient to insure interoperability:  

In addition, as I also mentioned in my previous message, I think that a URI
scheme that's restricted to ZIP may be too narrow. I agree with the
sentiments that led to a proposal for some way of covering rooted
directories, whether packaged or not, although I'm not certain about the
opera proposal itself: 


Received on Thursday, 12 June 2008 14:35:38 UTC