Re: Literal slashes in javascript: IRIs

* Henri Sivonen wrote:
>http://tools.ietf.org/html/draft-hoehrmann-javascript-scheme-00 says:
>> Use of a byte order mark and literal use of the character "/" should  
>> be avoided.
>
>The latter requirement seems impractical. Why is this requirement  
>present? Could it be relaxed?

How is it "impractical"? This essentially replicates RFC 4395 2.2,

  URI schemes that are not intended for use with relative URIs SHOULD
  avoid use of the forward slash "/" character, which is used for
  hierarchical delimiters, and the complete path segments "." and ".."
  (dot-segments).
  ...
  URI schemes that do not contain a conformant hierarchical structure
  in their <scheme-specific-part> SHOULD NOT use double slashes
  following the "<scheme>:" string.

Which of these would you want me to break with, and what argument could
I use to persuade the IETF community, the IESG, and the URI Scheme re-
viewer that either or both must be optional for 'javascript:'? Note that
my text is "should be avoided" which is slightly weaker than a possible
"SHOULD NOT use" with RFC 2119 implications, precisely because using the
slashes ala javascript:example('example/example.html') is quite common.

Also note this suggestion in the draft:

  A common error in 'javascript' resource identifiers is incorrect use
  of fragment identifiers as in <javascript:_scrollTo('#example')>, and
  some applications might have to recover from such errors.  Designers
  of protocol elements that accept resource identifiers as defined in
  this document should consider this case and, where compatibility is a
  concern, define a pre-processing step that percent-encodes all '#'
  characters before the content of the protocol element is processed as
  'javascript' resource identifier.

The same can be done for slashes (you would define e.g. an attribute by
saying the value is a string that is turned into a resource identifier
reference by doing something about backslashes, spaces, ... and if it
starts with 'javascript:' you escape slashes, #, etc. as necessary, and
then process the result as IRI Reference or whatever; a conformance
testing tool would then not report a warning since by the time it checks
for scheme-conformance the slashes would be gone). This is not pretty,
but it would not be pretty either to define that the #example part is
actually content and break with the RFC 4395 requirements above.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Friday, 23 November 2007 11:41:10 UTC