Vincent Massol wrote:
ok so far we have:
* Jerome: iii)
* Anca: iii)
* ThomasE (non-binding): iii)
* Vincent: iii)
Sergiu, ThomasM, JV, Marius, Asiri (and other committers): are you ok
with iii). Barring any more answers, I'll start implementing it in 1
hour (it seems the right solution to me anyway).
+1 for both ii) and iii)
iii) is good because it allows to have different URIs specify different
actions. By the way, we could extend the URI prefix so that if there is
no special handler for a prefix, we could use it as the action, for
example: [[feed:Blog.BlogRSS]] would link to
/xwiki/bin/feed/Blog/BlogRSS. At the moment this prevents FQN links to
other wikis, so we should decide when to change the FQN syntax.
ii) is good because it allows us to specify custom attributes on any
element/section, which would be needed for microformats (which rely on
class, rel, and title mostly), styling, and with the use of namespaces
we can add our own attributes and bind custom behavior on them. Anyway,
this is not a priority now, just something for the (not so far) future.
Implementation note: I'll still introduce an
onImage() event and an
ImageBlock class. Also as Jerome mentioned I'll use the text specified
as the label as is.
Thanks
-Vincent
On Oct 28, 2008, at 6:53 AM, Jerome Velociter wrote:
> I'd go for iii), without parsing the label (use "hello **world**" if
> it
> is, not make it "hello world")
>
> Jerome.
>
> Vincent Massol wrote:
>> On Oct 27, 2008, at 2:01 PM, Vincent Massol wrote:
>>
>> [snip]
>>
>>> Basically there are now 2
>>> possibilities:
>>>
>>> i) using a special syntax for parameters for links and images. For
>>> links that could be [[label>>reference>>>parameters]]. Note
that we
>>> might also need such a special syntax for inline verbatim blocks.
>>> ii) using 2 generic syntaxes for parameters:
>>>
>>> (% ... %) for applying parameters only to the next element
>>> {% ... %} ... {%%} for applying parameters to the elements inside
>>>
>>> Which one do you prefer?
>>>
>>> I think we have an issue for i) anyway (for verbatim inline elements
>>> for example).
>>>
>>> My preference goes to ii) [EDITED: was i)].
>> After speaking to Mikhail (wikimodel creator) there's a third
>> possibility:
>>
>> iii) using the same syntax for links, images and attachments. Namely:
>>
>> Links:
>> [[label>>reference||params]]
>>
>> Images:
>> [[label>>image:wiki:Space.Page^my.png||params]]
>>
>> Attachments (download link):
>> [[label>>attach:wiki:Space.Page^my.png||params]]
>>
>> This means that it would also be possible to use links, images and
>> attachments directly in the text using the form:
>>
>> This is a http://... URL
>> This is an image:my.png image
>> This is my word attach:my.doc document
>>
>> Notes:
>> * The "label" for images would correspond to the alt/title attribute.
>> Thus the wiki syntax inside would be transformed into text (for
>> example: "Hello **world**" would generate "Hello world")
>> * It would currently not be possible to disambiguate between a
>> subwiki
>> named "image", "attach" and displaying an image or linking to
an
>> attachment. This would be fixed later on when we change the FQN
>> (Fully
>> Qualified Name) for Documents in order to support nested spaces.
>> * This means that we can keep using (% %) notation and there's no
>> need
>> to define a new {% ... %} notation.
>> * It means we need to introduce the "||" separator for link
>> parameters
>> * It is completely inline with the wikimodel way of handling images.
>> * There's no need to introduce a new onImage() event. However we
>> might
>> want to rename our begin/endLink() events to beginReference()/
>> endReference().
>>
>> I personally like this solution except for the fact that since we've
>> introduced wiki syntax in place of labels we would be tweaking the
>> model a bit since there's no need for begin/end for images. That said
>> we could also add an onImage() event and emit it at the parser level
>> so that the label would always contain pure text (if we have "hello
>> **world**" we would use "hello **world**").
>>
>> I'm hesitating between ii) and iii).
>>
>> WDYT?
>>
>> Thanks
>> -Vincent
>>
>>>> so
>>>> +1 for 1)a) only if we can do it for all inline elements.
>>>>
>>>> Which brings us to images:
>>>> I find a wiki syntax quite suitable, for consistency reasons (with
>>>> links, for
>>>> example). ! is a pretty used character, even duplicated, so I'd go
>>>> for another
>>>> one: pipe (hard to find on some kbds, though), @ (semantically
>>>> associated with
>>>> emails, though), # (already taken), & ?
>>>>
>>>> so
>>>> +1 for wiki syntax for 2)
>>>>
>>>> Happy coding,
>>>> Anca
--
Sergiu Dumitriu
http://purl.org/net/sergiu/