On Oct 29, 2008, at 3:26 PM, Vincent Massol wrote: > > 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:[EMAIL PROTECTED] >>> >>> 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:[EMAIL PROTECTED]: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?
Right now I can think of only 1 advantage: The ability to insert an image inline in the text when the image comes from a different document: "This is an inline image:[EMAIL PROTECTED] image" 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. >>> _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
