[xwiki-devs] [Proposal] Choosing the separator character for representing the FQN of an attachment (new rendering)
29 Oct
2008
29 Oct
'08
10:52 a.m.
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: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.
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
29 Oct
29 Oct
12:15 p.m.
New subject: [xwiki-devs] [Proposal] Choosing the separator character for representing the FQN of an attachment (new rendering)
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:Space.Page@my.doc
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
12:35 p.m.
New subject: [xwiki-devs] [Proposal] Choosing the separator character for representing the FQN of an attachment (new rendering)
Jerome Velociter wrote:
Hello,
sounds pretty ok, +1
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:Space.Page@my.doc
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"]]
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
12:39 p.m.
On Oct 29, 2008, at 12:35 PM, Anca Paula Luca wrote:
Jerome Velociter wrote:
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
Hello,
sounds pretty ok, +1
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:Space.Page@my.doc
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"]]
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
>>
12:34 p.m.
New subject: [xwiki-devs] [Proposal] Choosing the separator character for representing the FQN of an attachment (new rendering)
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: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.
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:Space.Page@my.png right?
WDYT?
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
3:19 p.m.
New subject: [xwiki-devs] [Proposal] Choosing the separator character for representing the FQN of an attachment (new rendering)
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/
3:26 p.m.
On Oct 29, 2008, at 3:19 PM, Sergiu Dumitriu wrote:
Vincent Massol wrote:
You mean dropping the URI?
Otherwise that would mean:
[[attach:wiki:Space.Page@attachent:file.png]]
which is ugly (attachment is specified twice)
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.
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
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.
>
3:36 p.m.
On Oct 29, 2008, at 3:26 PM, Vincent Massol wrote:
On Oct 29, 2008, at 3:19 PM, Sergiu Dumitriu wrote:
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:Space.Page@my.ong image"
Thanks
-Vincent
Vincent Massol wrote:
You mean dropping the URI?
Otherwise that would mean:
[[attach:wiki:Space.Page@attachent:file.png]]
which is ugly (attachment is specified twice)
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.
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? 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.
>>
5898
days inactive
5898
days old
7 comments
5 participants
participants (5)
-
Anca Paula Luca -
Jerome Velociter -
Marius Dumitru Florea -
Sergiu Dumitriu -
Vincent Massol