Re: [SMW-devel] Making #set a true semantic call

[Yaron K. <ya...@gm...>]

Well, all of this makes sense. Just to confirm, it's not planned to ever
have #declare or #set produce a display, other than error messages?
I ask about all of this because I'm thinking of having Semantic Forms
support #set and/or #declare, both in parsing templates and in creating
them.

-Yaron


On Mon, Jan 19, 2009 at 1:35 PM, Markus Krötzsch <
ma...@se...> wrote:

> On Dienstag, 13. Januar 2009, Yaron Koren wrote:
> > On Mon, Jan 12, 2009 at 5:25 AM, Markus Krötzsch <
> >
> > ma...@se...> wrote:
> > >  I do not want to contribute to the general
> > > interface discussion here,
> >
> > Well, I'd like to hear your opinion on the issue, if possible - yours is
> > obviously the most relevant one.
>
> I don't really think so. I must say that I don't care much about syntax.
> But
> since you are asking I can explain some technical considerations that I
> have
> when thinking about new input methods:
>
> * Parsing [[ ]] is not easy and requires us to look through the wiki-text
> string for matching patterns. This causes some issues since the PHP library
> we
> use crashes on large matches. This is why nested annotations and links were
> disabled. In contrast, parsing {{ }} is done by MediaWiki for us, and
> nesting
> annotations is not a (technical) problem there.
>
> * Parsing [[ ]] is not clean since it happens at a stage during parsing
> where
> MediaWiki has half-processed the input. This makes the whole thing somewhat
> messy and undefined. Parsing {{ }} is clearly preferred there, since {{ }}
> have a clear place in the DOM of MediaWiki.
>
> * Parsing annotations requires database lookups, e.g. to get the type of
> some
> property. Technically, it would be desirable to collect many database calls
> into one (or at least into few). This might be easier with inputs like #set
> or
> true semantic templates where many inputs are collected within one parser
> function. Annotations spread all over the page would require multiple runs
> to
> first gather, then jointly parse, and finally output all annotations.
>
> In addition, I think that it is nice if users can see the output SMW gives
> after processing some annotation value (as opposed to #set). For example,
> this
> could include tooltips, hyperlinks, or warning messages. Some datatypes
> such
> as Code also provide more complex formating for data, which is rather
> useful
> to have.
>
> Summing up those four points, and adding my further experience that most
> SMW
> sites will want to use SemanticForms, I arrive at the following conclusion:
>
>
>  SMW's primary input mechanism should be an extended form of the current
> semantic templates (#declare). Annotations would be declared (this works
> already) on template pages, so that some parameters get annotated
> automatically without the need of [[ ]] syntax in the template code. Pages
> then simply use the template, provide parameters as usual, and some of the
> latter are turned into annotations and displayed accordingly (this is what
> does not work yet; #declare does not display any SMW output, not even
> errors).
>
>
> To do this, someone needs to extend #declare (and the associated
> processing)
> so that annotated parameters are replaced by the texts that SMW returns
> when
> processing the values (including error messages and the like). Like the
> current [[ ]] thing, this approach is still universal in the sense that
> every
> wiki could be modified to use only those "semantic templates" and still
> would
> look and work exactly the same way. Yet, no more [[ ]] parsing would be
> needed
> (of course we would keep this as an optional input for backwards
> compatibility).
>
> -- Markus
>
> P.S. I also think that a syntax with {{ }} is more likely to be compatible
> with existing and future WYSIWYG extensions, all of which will probably
> support template invocation, but most of which will misread [[ :: ]]
> pieces.
>
> >
> > -Yaron
>
>
> --
> Markus Krötzsch
> Semantic MediaWiki    http://semantic-mediawiki.org
> http://korrekt.org    ma...@se...
>
>