[xwiki-devs] [Proposal] Choosing the separator character for representing the FQN of an attachment (new rendering)
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. 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. 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"]] This sounds reasonable to me too. I think the real question is whether we need a textual representation of an attachment FQN or not. WDYT? Thanks -Vincent
Hello,
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.
For example: attach:wiki:[email protected]
looks good, +1
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.
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"]]
This sounds reasonable to me too. I think the real question is whether we need a textual representation of an attachment FQN or not.
Do we have use cases already for such FQN ? Annotations ? Jerome.
WDYT?
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Jerome Velociter wrote:
Hello,
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.
For example: attach:wiki:[email protected]
looks good, +1
sounds pretty ok, +1
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.
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"]]
Would we want to pass other parameters than ones that can be directly copied in html attributes?
This sounds reasonable to me too. I think the real question is whether we need a textual representation of an attachment FQN or not.
Do we have use cases already for such FQN ? Annotations ?
Jerome.
WDYT?
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Oct 29, 2008, at 12:35 PM, Anca Paula Luca wrote:
Jerome Velociter wrote:
Hello,
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.
For example: attach:wiki:[email protected]
looks good, +1
sounds pretty ok, +1
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.
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"]]
Would we want to pass other parameters than ones that can be directly copied in html attributes?
Yes definitely. Parameters are not about HTML parameters. This is something independent of the target syntax and meant to provide qualifiers for the element. So non visual parameters are very fine. 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.
Do we have use cases already for such FQN ? Annotations ?
Jerome.
WDYT?
Thanks -Vincent
Hi Vincent, 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 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.
I don't have a use case too, but I fill this would be very useful at some point. It's a good thing to be able to reference any part of our model. I'm +1 for it.
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"]]
This sounds reasonable to me too. I think the real question is whether we need a textual representation of an attachment FQN or not.
By using link parameters we won't be able to use the short form attach:wiki:[email protected] right?
WDYT?
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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 @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/
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: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.
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: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?
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.
participants (5)
-
Anca Paula Luca -
Jerome Velociter -
Marius Dumitru Florea -
Sergiu Dumitriu -
Vincent Massol