Recent Pages

Commands at a glance
edittable: trivial tabl ...
indextable: generate ta ...
NoSQL Utilities
Text Formatting Rules
Site SandBox
Change Management
Wiki Editor's How-To
Site Terms of Use
Site Copyright


NoSQL Home
Table of Contents
Wiki Editor's How-To
Text Formatting Rules
Wiki SandBox on Twitter


Google Ads

Please Support NoSQL !


User ID

Campaigns petition banner


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.

This is a thick line:

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 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.

Column AColumn BColumn C
Entry for row 1, Column AEntry for row 1, Column BEntry for row 1, Column C
Entry for row 2, Column AEntry for row 2, Column BEntry for row 2, Column C
Spanning entry Entry for row 3, Column C
More spanning

Testing with malicious javascript code injection:

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

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

aaa <del>goofy</del> bbb ccc

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.

Sample extra entry that does not parse as RDFa and is left unparsed:

(:vvvv aaa bbb:)

Other stuff belonging into the current "organization" context:

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

Some Street 1, 123 Some 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:

54321 USA

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:

Gizmo Gadgets A Nifty Useless Tingie 123.40

Sample "review" entry; this is meaningless inside the previous "product" context, so a new top-level "review" context is started (reviews are toplevel-only elements):

Komala Vilas 1 Meenakshi Ammal 1.1 1st April 2005 Best vegetarian food 1

Sample "review" entry, with optional URI/URL/CURIE that will be used to build the RDF "about" property of the entry (this is currently supported by Google only for Reviews and Review-aggregates): Komala Vilas 2 Meenakshi Ammal 2.2 2nd April 2005 Best vegetarian food 2

Sample "review" entry, with optional blank-node CURIE:

Komala Vilas 3 Meenakshi Ammal 3.3 3rd April 2005 Best vegetarian food 3

Sample "review aggregate" (this one too supports optional URI/URL/CURIE):

Komala Vilas 4 3.7 20 Best vegetarian food 4

Sample "review" entry, with the reviewer being an organization instead of simple #CDATA with the name of the author; note also the geographical coordinates:

Komala Vilas 5 ACME Example 3 Inc. +3 (0)234 123456 45.123 9.456 Some Street 2, 123 Some Town 3 3.8 4th April 2005 Best vegetarian food 5

Sample "review", again by an organization, where "v-telephone" has been placed after the last element of the "address" context ("v-locality"):

Komala Vilas 6 ACME Example 4 Inc. Some Street 3, 123 Some Town 4 +4 (0)234 123456 3.9 5th April 2005 Best vegetarian food 6

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":

Komala Vilas 7 ACME Example 5 Inc. Some Street 4, 123 Some Town 5 4.0 (:v-telephone +5 (0)234 123456:) (:v-date 6th April 2005:) (:v-summary Best vegetarian food 7:)

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:

Komala Vilas 8 ACME Example 6 Inc. Some Street 5, 123 Some Town 6 Some Other Street 6, 123 Some Other Town 7

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:

Komala Vilas 9 ACME Example 7 Inc. +6 (0)234 123456 Some Street 7, 123 Some Town 8 4.1 7th April 2005 Best vegetarian food 8

John Smith Jr. 1 General Manager 1

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:

Komala Vilas 10 ACME Example 8 Inc. +7 (0)234 123456 Some Street 8, 123 Some Town 9 4.2 8th April 2005 Best vegetarian food 9

John Smith Jr. 2 General Manager 2

Sample "person" entry, with an embedded address block (if the specified image URL does not exist, the browser will show the image URL verbatim, otherwise the actual image will be shown):

John Smith Jr. 3 Some Street 9, 892 Some Town 10 NY 56671 USA

Sample XFN properties of the current "person" context: Brad 1

Same as above, but with multi-valued 'rel' attribute, which is supported by the XFN specs but not by Google, so I omit the "v:" namespace prefix on output: Brad 2

Another XFN properties of the current "person", in a free-link format:

Same as above, but with multi-valued 'rel' attribute, which is supported by the XFN specs but not by Google, so I omit the "v:" namespace prefix on output:


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, ...

Testing with IPv6 ....

Testing with emoticons ... ...

Trackbacks (0) | New trackback | Comments (0) | Print

This Web Site is Copyright © 2007,2008,2009,2010 Carlo Strozzi, Some Rights Reserved
site map | recent changes | terms of use