- From: Erik Wilde <net.dret@dret.net>
- Date: Thu, 11 Jul 2002 18:28:37 +0200
- To: uri@w3.org
hello. i have authored an internet draft for fragment identifiers for text/plain resources. the draft's abstract reads: "This memo defines URI fragment identifiers for text/plain resources. These fragment identifiers make it possible to refer to parts of a text resource, identified by character count or range, line count or range, or a regular expression. These identification methods can be combined to identify more than one sub-resource of a text/plain resource." you can find the draft in text and html form in the usual internet draft archives (maybe after a one or two day delay) and at the following locations: http://dret.net/netdret/docs/draft-wilde-text-fragment-00.txt http://dret.net/netdret/docs/draft-wilde-text-fragment-00.html currently i have the following open questions for the draft's next version: - should there be more schemes? or less? - is the concatenation of schemes a good thing? or a bad thing? - it seems to be impossible to give a proper definition of StringWithBalancedParens using rfc 2234 abnf. is this right? if so, is it a problem? - does anybody have a nice reference or syntax for iso 9945-2 bres? is there a rfc defining bres? is it a good idea to use iso 9945-2 bres? if not, which kind of regex should be used? xml schema's regex, which has nice support for unicode? - regexes by themselves may identify disjoint sub-resources. should there be a mechanism to say something like "the 5th appearance of the following regex"? or are users responsible for composing regexes which do not need this kind of additional mechanism? - should there be more text about url encoding? or is it safe to assume that people know that urls must be encoded in a special way? any comments are very welcome. cheers, erik wilde - tel:+41-1-6325132 - fax:+41-1-6321035 mailto:net.dret@dret.net - http://dret.net/ computer engineering and networks laboratory swiss federal institute of technology (eth) * try not. do, or do not. there is no try. *
Received on Thursday, 11 July 2002 12:29:55 UTC