On Oct 29, 2008, at 3:19 PM, Sergiu Dumitriu wrote:
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
You mean dropping the URI?
Otherwise that would mean:
[[attach:wiki:Space.Page@attachent:file.png]]
which is ugly (attachment is specified twice)
@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"]]
platform is not a valid URI so it means it's pointing to a document.
In the future we've already discussed that document FQN would be non
ambiguous with URI (using "::" for example).
So the real question in my mind is: do we need a FQN for attachments?
Thanks
-Vincent
> This sounds reasonable to me too. I think the real
question is
> whether
> we need a textual representation of an attachment FQN or not.
>