Conflict in 0.8 spec

[Kevin Brown]

MODULE_PREFS_SPEC-001 calls for <Link> elements with "gadgets help" and "gadgets support" being two possible values (no mention of what they're supposed to mean).

LIFECYCLE_EVENTS-001 calls for <link> (note lower case) elements with very different behavior depending on the rel attributes. It doesn't specify where in the spec these <link> elements are supposed to be placed.

It seems to me that the spec needs to take the XSD changes from MODULE_PREFS_SPEC-001 and merge the rel attributes. Prose is needed to specify behavior for the different rel categories (events are more specific behavior -- help and support are just metadata). This makes the valid rel attributes:

- Everything mentioned in LIFECYCLE_EVENTS-001
- "gadgets help" and "gadgets support"

I'd also like to standardize at least one more rel attribute, "icon". This would eliminate the need to redefine / update the <Icon> tag and allows us to remove it in the future (since nobody actually implemented it, that could probably be "now").

[Paul Lindner]

My recommendation is to go with the lowercase <link> tag, as is used in HTML today.

I also recommend that we use rel=”gadgets.help” and rel=”gadgets.support” as the contact channels.  The href attribute can be used to point at a web page or a mailto: url to satisfy the user’s request for help and/or support.

+1 on the icon issue too, we’d to get that aligned with web standards too.

[John Hjelmstad]

The Canonical XSD has already been updated with a single <Link> tag, which as far as I can tell coalesces LIFECYCLE-EVENTS_001 and MODULE-PREFS_001 syntactically. I agree on the need for prose describing <Link>'s use, but little to none was actually approved on the spec discussion threads, and I am loath to unilaterally add a significant related chunk. We absolutely must do so in either an out-of-band cleanup or at latest, during the v0.9 process.

That said, there are some changes that do make sense now:

* +1 on consolidating icon. v0.9, or would you suggest adding something like a "deprecated" comment in the XSD?

* +0 on <Link> to <link>. The former is consistent w/ the existing capitalization scheme. The latter is consistent w/ HTML. Anyone else have a strong opinion?
* +1 on valid rel-values stored as an enum. How about:
<enumeration value="gadgets.help"/>
<enumeration value="gadgets.support"/>
<enumeration value="icon"/>
...with the requisite XSD stuff around same.

Other comments? Do folks agree?

--John

[Graham Spencer]

I agree with John's +1s, so the same from me. On <Link> vs. <link> -- I have a very mild preference for sticking with <Link> until we overhaul the gadgets spec at some point in the future and then converting to <link>. But in the interests of expedience, you can cast my +1 with the first 4 +1s in either direction...

--g

[Louis Ryan]

Same here. Lets retain Link until the overhaul.

[Paul Lindner]

Considering that <Link> is new in 0.8, I’d prefer to see it use html norms — which is consistent with the assertion that OpenSocial lets you leverage your existing web knowledge instead of learning something new...

Otherwise I’m +0 on an enum for rel=”” values.  I expect that this area would be a fertile place for implementers that want to extend the default metadata.

Perhaps consider a xsd:restriction that allows for the defined values plus anything starting with x- (”^x-.*”) ?

[Zhen Wang]

+1 on <Link> which is consistent with existing naming convention.

[Paul Lindner]

Okay, <Link> it is...

[Kevin Brown]

On Thu, May 22, 2008 at 4:05 PM, Paul Lindner <plin...@hi5.com> wrote:
> Considering that <Link> is new in 0.8, I'd prefer to see it use html norms —
> which is consistent with the assertion that OpenSocial lets you leverage
> your existing web knowledge instead of learning something new...

I prefer lower case as well, but the capital L is consistent with the rest of the spec. *shrug*.

>
> Otherwise I'm +0 on an enum for rel="" values.  I expect that this area
> would be a fertile place for implementers that want to extend the default
> metadata.

I agree that implementors should be allowed to extend, but we should have a well-defined way to do that so that we don't get naming conflicts, and the enumeration could be interpreted only for the well-defined values, such as lifecycle events.

>
> Perhaps consider a xsd:restriction that allows for the defined values plus
> anything starting with x- ("^x-.*") ?

Yes!

> On 5/21/08 6:21 PM, "Kevin Brown" <et...@google.com <http://etnu@google.com>

[Dan Peterson]

On Thu, May 22, 2008 at 5:55 PM, Kevin Brown <et...@google.com> wrote:

On Thu, May 22, 2008 at 4:05 PM, Paul Lindner <plin...@hi5.com> wrote:
> Considering that <Link> is new in 0.8, I'd prefer to see it use html norms —
> which is consistent with the assertion that OpenSocial lets you leverage
> your existing web knowledge instead of learning something new...

I prefer lower case as well, but the capital L is consistent with the rest of the spec. *shrug*.

Zhen raises a good point re: internal consistency (the XML file is XML, not HTML...) so I am now convinced of <Link> being the better option as well.

My read on this is that folks who preferred <link> are actually ok with <Link> as well, is that correct?

Any major dissent?

-Dan

[John Hjelmstad]

+1 on enum plus x-.+!