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

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:

http://www1.example.comle.com

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 http://www2.example.com/products/p25

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

http://www.example.com Komala Vilas 2 Meenakshi Ammal 2.2 2nd April 2005 Best vegetarian food 2

Sample "review" entry, with optional blank-node 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:

John Smith Jr. 3 http://www.example.org/~jsmith 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 different format: http://brad-log3.example.org Brad3

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: http://brad-log4.example.org Brad4

Carlo

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

 (::db:)
 use             course course_student student
 read            course
 expression      $Course == "chem-1"
 join            - course_student
 columns         Student Course
 order-by        -
 join            - student
 columns         Course First Last Phone
 format          example
 (:db::)