Vincent Massol wrote:
Hi,
I had proposed to use the ^ character as attachment delimiter.
Ex: wiki:Space.Page^attachment
However I've just realized while implementing it that it's an "unwise"
character in an URI
(source:
http://www.ietf.org/rfc/rfc2396.txt)
unwise = "{" | "}" | "|" | "\" |
"^" | "[" | "]" | "`"
Allowed punctuations characters are:
mark = "-" | "_" | "." | "!" |
"~" | "*" | "'" | "(" | ")"
BTW the following are reserved:
reserved = ";" | "/" | "?" | ":" |
"@" | "&" | "=" | "+" | "$" |
","
Note that we use ":" for wiki delimiter but that's okay since we're
using an opaque URI and thus reserved chars, unreserved chars and
escaped chars are authorized.
I think it would be better to choose amongst one the valid chars for
the attachment to prevent future problems.
Of course this means we'll have to make that character forbidden in a
page name. Actually we could also decide that it's character forbidden
in an attachment (and use lastIndexOf() instead of indexOf() to
separate the page name from the attachment name). Or we could double
it once again...
I propose we use the @ symbol since it's not a char used often in page
names.
+0 for @.
For example:
attach:wiki:Space.Page@my.doc
This raises the discussion of the full FQN we'd like to have when we
support nested spaces too. For example:
(wiki name) "::" (space name) [ "." (space name)]* "::"
(page name)
["@" (attachment name)]?
Now what about referencing objects and properties using a URI too? Do
we want that? What would be the use? Right now I don't see a use and
using an API to access them seems fine to me.
We could use a (kind of) XPath:
@attachment:file.png
@object:XWiki.XWikiRights[0]/level
@class:XWiki.XWikiRights/level/default
The problem is that the XPath starts after the @, so it's not a full
XPath. This needs to be investigated further.
Alternative view
============
We could also only specify the attachment name in the uri and use link
parameters to specify the document where it's located as in:
[[image:my.png>>document="wiki:Space.Page"]]
How do we make the difference between this and:
[[platform:Main.WebHome>>target="_blank"]]
This sounds reasonable to me too. I think the real
question is whether
we need a textual representation of an attachment FQN or not.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/