On Tue, 25 Aug 2009 00:29:06 +0200, Ian Hickson <i...@hixie.ch> wrote:
On Mon, 24 Aug 2009, Philip Jägenstedt wrote:
I've found two related things that are a bit problematic. First, because
itemprops are only associated with ancestor item elements or via the
subject attribute, it's always necessary to find or create a separate
element for the item. This leads to more convoluted markup for small
items, so it would be nice if the first item and itemprop could be on
the same element when it makes sense:
<p item="vevent" itemprop="description">
Concert at <span itemprop="dtstart">19:00</span> at <span
itemprop="location">the beach</span>.
</p>
rather than
<p item="vevent">
<span itemprop="description">
Concert at <span itemprop="dtstart">19:00</span> at <span
itemprop="location">the beach</span>.
</span>
</p>
As specced now, having itemprop="" and item="" on the same element
implies
that the value of the property is an item rooted at this element.
Not supporting the above was intentional, to keep the mental model of the
markup very simple, rather than having shortcuts. (RDFa has lots of
shortcuts and it ended up being very difficult to keep the mental model
straight.)
There's something like an inverse relationship between simplicity of the
syntax and complexity of the resulting markup, the best balance point
isn't clear (to me at least). Perhaps option 3 is better, never allowing
item+itemprop on the same element.
Second, because composite items can only be made by adding item and
itemprop to the same element, the embedded item has to know that it has
a parent and what itemprop it should use to describe itself. James gave
the example of "something like planet where each article could be a
com.example.blog item and within each article there could be any
arbitrary author-supplied microdata" [1]. I also feel that the
item+itemprop syntax for composite items is one of the least intuitive
parts of the current spec. It's easy to get confused about what the type
of the item vs the itemprop should be and which item the itemprop
actually belongs to.
Fair points.
Given that flat items like vcard/vevent are likely to be the most common
use case I think we should optimize for that. Child items can be created
by using a predefined item property: itemprop="com.example.childtype
item".
Ok...
The value of that property would then be the first item in tree-order
(or all items in the subtree, not sure). This way, items would have
better copy-paste resilience as the whole item element could be made
into a top-level item simply by moving it, without meddling with the
itemprop.
That sounds kinda confusing...
More confusing than item+itemprop on the same element? In many cases the
property value is the contained text, having it be the contained item
node(s) doesn't seem much stranger.
If the parent-item (com.example.blog) doesn't know what the child-items
are, it would simply use itemprop="item".
I don't understand this at all.
This was an attempt to have anonymous sub-items. Re-thinking this, perhaps
a better solution would be to have each item behave in much the same way
that the document itself does. That is, simply add items in the subtree
without using itemprop and access them with .getItems(itemType) on the
outer item.
Comparing the current model with a DOM tree, it seems odd in the a
property could be an item. It would be like an element attribute being
another element: <outer foo="<inner/>"/>. That kind of thing could just as
well be <outer><foo><inner/></foo></outer>, <outer><inner
type="foo"/></outer> or even <outer><inner/></outer> if the relationship
between the elements is clear just from the fact that they have a
parent-child relationship (usually the case).
All examples of nested items in the spec are on the form
<p itemprop="subtype" item>
These would be replaced with
<p item="subtype">
It's only in the case where both itemprop and item have a type that an
extra level of nesting will be needed and I expect that to be the
exception. Changing the model to something more DOM-tree-like is probably
going to be easier to understand for many web developers. It would also
fix the problem in my other mail where it's a bit tricky to determine via
the DOM API whether a property is a string or an item. When on the topic
of the DOM API, document.getItems("outer")[0].getItems("inner")[0] would
be so much clearer than what we currently have.
Example:
<p item="vcard" itemprop="n item">
My name is <span itemprop="given-name">Philip</span>
<span itemprop="family-name">Jägenstedt</span>.
</p>
I don't understand what this maps to at all.
The same as
<p item="vcard">
<span itemprop="n" item>
My name is <span itemprop="given-name">Philip</span>
<span itemprop="family-name">Jägenstedt</span>.
</span>
</p>
Unless I've misunderstood the "n" in vcard (there's no example in the
spec). But let's move on.
I'll admit that my examples are a bit simple, but the main point in my
opinion is to make item+itemprop less confusing. There are basically
only 3 options:
1. for compositing items (like now)
2. as shorthand on the top-level item (my suggestion)
3. disallow
I'd primarily like for 1 and 2 to be tested, but 3 is a real option too.
[1] http://krijnhoetmer.nl/irc-logs/whatwg/20090824#l-375
We can't disallow nesting items as values of properties, there are a
whole
bunch of use cases that depend on it.
3 is not a suggestion to disallow nesting, but to change the syntax for it.
Could you show how your syntax proposals would look when marking up the
following data?
// JSON DESCRIPTION OF MARKED UP DATA
// document URL: http://www.example.org/sample/test.html
{
"items": [
{
"type": "com.example.product",
"properties": {
"about": [ "http://example.com/products/bt200x"; ],
"image": [ "http://www.example.org/sample/bt200x.jpeg"; ] //
please keep this one outside the item in the DOM
"name": [ "GPS Receiver BT 200X" ],
"reldate": [ "2009-01-22" ],
"review": [
{
"type": "",
"properties": {
"reviewer": [ "http://ln.hixie.ch/"; ],
"text": [ "Lots of memory, not much battery, very little
accuracy." ]
}
}
],
}
},
{
"type": "work",
"properties": {
"about": [ "http://www.example.org/sample/image.jpeg"; ],
"license": [
"http://www.opensource.org/licenses/mit-license.php"; ]
"title": [ "My Pond" ],
}
}
]
}
Here's how it would be marked up today:
<section id="bt200x" item=com.example.product>
<link itemprop=about href="http://example.com/products/bt200x";>
<h1 itemprop=name>GPS Receiver BT 200X</h1>
<p>Rating: ⋆⋆⋆✩✩ <meta
itemprop=rating content="2"></p>
<p>Release Date: <time itemprop="reldate" datetime="2009-01-22">January
22</time></p>
<p itemprop=review item><a itemprop=reviewer
href="http://ln.hixie.ch/";>Ian</a>:
"<span itemprop=text>Lots of memory, not much battery, very little
accuracy.</span>"</p>
</section>
<figure item=work>
<img itemprop=about src="image.jpeg">
<legend>
<p><cite itemprop="title">My Pond</cite></p>
<p><small>Licensed under the <a itemprop="license"
href="http://www.opensource.org/licenses/mit-license.php";>MIT
license</a>.</small>
</legend>
</figure>
<p><img subject="bt200x" itemprop="image" src="bt200x.jpeg"
alt="..."></p>
To be clear, I'm now suggesting that item+itemprop never be allowed on the
same item (option 3). Nesting items is accomplished simply by nesting them.
In your example, the only change would be this line:
<p item=review><a itemprop=reviewer href="http://ln.hixie.ch/";>Ian</a>:
(Of course some tokens may need to change to be renamed to make sense as
item names rather than itemprops.)
As an aside, subject should also be allowed to associate items with its
parent item, just like for itemprop.
IMHO, this syntax is more copy-paste robust, favors the common cases over
the complex cases and makes the model more intuitive to those who
understand XML and/or DOM.
--
Philip Jägenstedt
Opera Software
![http://www.example.org/sample/bt200x.jpeg"](http://www.example.org/sample/bt200x.jpeg"){kind=link}
![http://www.example.org/sample/image.jpeg"](http://www.example.org/sample/image.jpeg"){kind=link}