SandBox

Please use this page to get acquainted with the page editing syntax of this Wiki, which is a subset of the UseMod Wiki syntax. If multiple users are editing this page at the same time, you may get an occasional concurrency error message and you will have to reload the original page and make your changes again.

write:

----

print:

write:

------

print:

Test newline ...
... continue

new paragraph

This is a CURIE-type URI [wiki:Biome], to see if it fools this parser into believing it's an hyperlink. It doesn't, that's good. See http://en.wikipedia.org/wiki/CURIE for more info.

Testing with a simple table. At the moment the only way to get finer-grained control on table properties is through a suitable CSS.

<form>
<input type="button" onclick=
"alert('Are you sure you want to give us the deed to your house?')"
value="Confirmation Alert">
</form>

aaa <del>goofy</del>

This is a test CPI: (:test:)

Experimenting with embedded RDFa:

Sample input:

Sample misplaced entry; since it belongs into the "address" context,
which is not open yet, it is left unparsed:

(:v-region WA:)

Open an "organization" context:

ACME Example 1 Inc.+1 (0)234 123456

In the previous example note the presence of "^45.123;9.456"
immediately following "Komala Vilas". The caret "^" stands for
"Abbreviation" and can be used to define an abbreviation for the
associated name. The exact type of abbreviation depends on the pattern
of caracters that follow the caret itself. Currently only embedded
geo-tagging is supported, but more abbreviation types may be added
in the future. Only one single abbreviation is taken into account,
i.e. if a pattern such as "Text^stuff1^stuff2" is specified, only
"Text^stuff1" will be considered. This seems reasonable since having
multiple abbreviations for the same piece of text seems useless.
Since RDFa has no provisions for abbreviations, I use the same
syntax produced by the Microformat scanner. See the source code of
the latter for more info on this.

Postal Address; since we have an "organization" context already open,
this is treated as that organization's address:

Some Street 1, 123Some Town 1

Entering the same element twice (see previous line) is probably incorrect
but the parser currently accepts it:

Some Other Town 2

Sample mistyped data (trailing ":" after "region") that will
be left unparsed:

(:v-region: NJ:)

Other components of the current "address" context follow:

54321USA

Organization after an address:

ACME Example 2 Inc.+2 (0)234 123456

Sample "product" entry; this is meaningless inside the current "address"
context", so it is sent one level above first, which is "organization",
and since it is invelid there too, a new top-level "product" context
is started:

When the parser meets "v-telephone" in the "address" context" it
will bail-out from that context and move up one level, which is
the "organization" context. Since "v-telephone" is valid in that
context, things will parse normally.

In the following example, "v-telephone" is misplaced after "v-rating":

When the parser meets "v-rating" in the "address" context it bails-out
to the parent "organization" context, and since "v-rating" is not valid
in that context either, it bails-out further to the "review" context,
where "v-rating" is valid. Then, while in the "review" context, the parser
meets "v-telephone", which is invalid in that context, and the bail-out
process starts again, with the parser climbing backwards until a valid
element/context combination is met. Up to then, all elements encountered
along the way will be left unparsed. Since no elements in the example
belong into any of the upper contexts, they will all be left unparsed
up to the end of the "review" context.

Entering two adjacent address blocks is probably incorrect,
but the parser currently accepts them:

In the next example a review done by an organization is followed by
a "person" block. Since reviews can take also persons as reviewers,
a "person" occurring while in a "review" context is considered a
reviewer. In this example therefore we will end up with having
two reviewers for the same review, that is an organization and a
person:

Having multiple reviewers in the same "review" context may be wrong for
Google's crawler, but the parser currently accepts it. If considering
"John Smith Jr." a second reviewer of "Komala Vilas" is not what we
mean, we must ensure to tell the parser by inserting a "v-break" element
between the end of the review and the beginning of the person:

In the above examples all tags have been written on a separate line
and without any interspersed text. That was done for readability, but
the whole purpose of the RDFa markup is the semantic labelling of
free-form text, so in practical situations a "person" definition
will be surrounded by- and interspersed with text, like this:

Lorem ipsum dolor sit amet

John Smith Jr. 4, consectetur
adipiscing elit General Manager 3

. Aenean convallis
scelerisque metus, ...

Below is an example of dynamic output, based on the following NoSQL NBL database query: