- 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