View level feature proposal for Open Social 2.0

[Matthew Marum]

For the view level features proposal, I've created issue 1133 and attached a patch with the proposed spec changes.

http://code.google.com/p/opensocial-resources/issues/detail?id=1133

Once again, the wiki for this proposal is located on the new opensocial wiki.

http://docs.opensocial.org/display/OSD/View+Level+Features+Proposal

Comments and feedback are more than welcome!

[James Snell]

Matthew, thank you for posting this. One thing that should be clarified in the proposal is that the views attribute is multi-valued. That is, if a particular required feature applies to multiple views, then that can be expressed as views="view1, view2"

- James

--
You received this message because you are subscribed to the Google Groups "OpenSocial and Gadgets Specification Discussion" group.
To post to this group, send email to opensocial-an...@googlegroups.com.
To unsubscribe from this group, send email to opensocial-and-gadg...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en.

[Matthew Marum]

Thanks James,

I've incorporated your comments.

One thing I wanted to ask the community is if there are compelling use cases for specifying views for other ModulePrefs elements?  We've got use cases for Require/Optional and Locale elements so those are included in the proposal.  But for other elements like Link or OAuth, we couldn't come up with good use cases.  If the community has some then we could expand this proposal.

- Matt

[Paul Lindner]

I can't think of any other use-cases at this point.

> --
> You received this message because you are subscribed to the Google Groups
> "OpenSocial and Gadgets Specification Discussion" group.
> To post to this group, send email to
> opensocial-an...@googlegroups.com.
> To unsubscribe from this group, send email to
> opensocial-and-gadg...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en.
>

--
Paul Lindner -- lin...@inuus.com -- linkedin.com/in/plindner

[James Snell]

Matthew, overall this looks great. The one thing I would note, however, is that the spec patch does not include any mention of the potential feature version conflicts and their handling. I'm wondering if we shouldn't at least acknowledge the possibility and offer some guidance in the spec. 

[Matthew Marum]

Thanks James, I beginning to agree.  I'm seeing not only that problem but an issue with how to handle feature parameters when you have multiple declarations of same feature.

A gadget developer may want to specify different parameters for a view level feature versus the set of parameters specified globally.  So I think in those cases you need to prefer the view level feature.  A quick example...

  <Module>
    <ModulePrefs>
      <Require feature="opensocial-1.1" />
      <Require feature="pubsubFake" views="default, canvas"/>
      <Require feature="pubsubFake" views="mobile">
        <Param name="isMobile">true</Param>
      </Require>
      <Require feature="views" />
      <Preload href="http://www.example.com" views="default"/>
    </ModulePrefs>
    <Content type="html" view="default, canvas">
      <![CDATA[ regular gadget content ]]>
    </Content>
    <Content type="html" view="mobile">
      <![CDATA[ mobile gadget content ]]>
    </Content>
  </Module>

More issues may come up as I finish up the patch for Shindig.  I haven't gone very far on view level Locales yet.

Matt Marum

[rbaxter85]

Matt, how would I specify different values for the same parameter that
applied to one feature? For example:

<Require feature="pubsubFake" views="default, canvas">

<Param name="foo">bar</Param>
</Require>

What if I wanted to specify a different value for foo for both default
and canvas views? Would I have to split them up?

<Require feature="pubsubFake" views="default">
<Param name="foo">bar</Param>
</Require>

<Require feature="pubsubFake" views="canvas">
<Param name="foo">world</Param>
</Require>

> > On Wed, Jan 19, 2011 at 12:00 AM, Paul Lindner <lind...@inuus.com> wrote:
>
> >> I can't think of any other use-cases at this point.
>

> >> On Mon, Jan 17, 2011 at 1:59 PM, Matthew Marum <mgma...@gmail.com> wrote:
> >> > Thanks James,
>
> >> > I've incorporated your comments.
>
> >> > One thing I wanted to ask the community is if there are compelling use
> >> cases
> >> > for specifying views for other ModulePrefs elements?  We've got use
> >> cases
> >> > for Require/Optional and Locale elements so those are included in the
> >> > proposal.  But for other elements like Link or OAuth, we couldn't come
> >> up
> >> > with good use cases.  If the community has some then we could expand
> >> this
> >> > proposal.
>
> >> > - Matt
>
> >> > --
> >> > You received this message because you are subscribed to the Google
> >> Groups
> >> > "OpenSocial and Gadgets Specification Discussion" group.
> >> > To post to this group, send email to
> >> > opensocial-an...@googlegroups.com.
> >> > To unsubscribe from this group, send email to

> >> > opensocial-and-gadg...@googlegroups.com<opensocial-and-gad gets-spec%2Bunsu...@googlegroups.com>
> >> .

> >> > For more options, visit this group at
> >> >http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en.
>
> >> --

> >> Paul Lindner -- lind...@inuus.com -- linkedin.com/in/plindner

>
> >> --
> >> You received this message because you are subscribed to the Google Groups
> >> "OpenSocial and Gadgets Specification Discussion" group.
> >> To post to this group, send email to
> >> opensocial-an...@googlegroups.com.
> >> To unsubscribe from this group, send email to

> >> opensocial-and-gadg...@googlegroups.com<opensocial-and-gad gets-spec%2Bunsu...@googlegroups.com>
> >> .

> >> For more options, visit this group at
> >>http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en.
>
> >  --
> > You received this message because you are subscribed to the Google Groups
> > "OpenSocial and Gadgets Specification Discussion" group.
> > To post to this group, send email to
> > opensocial-an...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > opensocial-and-gadg...@googlegroups.com<opensocial-and-gad gets-spec%2Bunsu...@googlegroups.com>
> > .

[Matthew Marum]

Yes, you would end up having to split them up.

Alternatively, we could allow individual Param elements to specify a views attribute, but I feel like that adds complexity.

<Require feature="pubsubFake" views="default, canvas">

 <Param name="foo" views="default">bar</Param>
 <Param name="foo" views="canvas">world</Param>
 <Param name="foo2">bar</Param>
</Require>

Matt

To unsubscribe from this group, send email to opensocial-and-gadg...@googlegroups.com.

[James Snell]

+1 to splitting.

>> > >> > opensocial-and-gadg...@googlegroups.com<opensocial-and-gadgets-spec%2Bunsu...@googlegroups.com><opensocial-and-gad
>> gets-spec%2Bunsu...@googlegroups.com<gets-spec%252Buns...@googlegroups.com>

>> >
>> > >> .
>> > >> > For more options, visit this group at
>> > >> >http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en.
>> >
>> > >> --
>> > >> Paul Lindner -- lind...@inuus.com -- linkedin.com/in/plindner
>> >
>> > >> --
>> > >> You received this message because you are subscribed to the Google
>> Groups
>> > >> "OpenSocial and Gadgets Specification Discussion" group.
>> > >> To post to this group, send email to
>> > >> opensocial-an...@googlegroups.com.
>> > >> To unsubscribe from this group, send email to

>> > >> opensocial-and-gadg...@googlegroups.com<opensocial-and-gadgets-spec%2Bunsu...@googlegroups.com><opensocial-and-gad
>> gets-spec%2Bunsu...@googlegroups.com<gets-spec%252Buns...@googlegroups.com>

>> >
>> > >> .
>> > >> For more options, visit this group at
>> > >>http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en.
>> >
>> > > --
>> > > You received this message because you are subscribed to the Google
>> Groups
>> > > "OpenSocial and Gadgets Specification Discussion" group.
>> > > To post to this group, send email to
>> > > opensocial-an...@googlegroups.com.
>> > > To unsubscribe from this group, send email to

>> > > opensocial-and-gadg...@googlegroups.com<opensocial-and-gadgets-spec%2Bunsu...@googlegroups.com><opensocial-and-gad
>> gets-spec%2Bunsu...@googlegroups.com<gets-spec%252Buns...@googlegroups.com>

[Matthew Marum]

Spec patch in issue and proposal wiki updated based upon feedback.

[Mark W.]

Why can't we just put the features under the content tag?

We'd have something like...

<Module>
    <ModulePrefs>
      <Require feature="opensocial-1.1" />

      <Require feature="views" />
      <Preload href="http://www.example.com" views="default"/>
    </ModulePrefs>
    <Content type="html" view="default, canvas">

      <Require feature="pubsub-2"/>
      <Require feature="tabs"/>
      <![CDATA[ stuff goes here ]]>
    </Content>
  </Module>

Anything at the top level is "global".
View specific features take precedence.

[Matthew Marum]

I like the readability of this idea.  The main reason why I went with using a views attribute was because Preload already used one, so I thought it would be best to be consistent.  This proposal also covers Locales too.

I think this idea is great for simple gadgets.  But if you have multiple content sections per view,  or many views with many content sections using the same features/locales, then I think it could make the gadget xml busy.

Matt

[mfra...@mitre.org]

+1 to Mark's suggestion. I think that the concerns you raised
regarding the gadget XML being busy is primarily a style issue and
could be avoided.

-Matt Franklin

> > opensocial-and-gadg...@googlegroups.com<opensocial-and-gad gets-spec%2Bunsu...@googlegroups.com>
> > .

[Mark W.]

BTW...

One of the work items that we have for 2.0 is a "real" schema. While I like NOT having one of these because schema validation, extension and what not can be a pain, it could be very useful.

That said... I'd like to know from the community if we want to tackle this. I think I'm neutral on the issue.

[James Snell]

-1 for the simple reason that, as Matthew points out, it is inconsistent with the existing Preload element and it causes unnecessary complication of the XML and complicates the processing of the Content element, particularly if the content is not wrapped in CDATA. Keeping all the Require/Optional/Preload/Locale elements together in one place is clean and degrades nicely. I just don't see any benefit to moving those into the Content element.

--
You received this message because you are subscribed to the Google Groups "OpenSocial and Gadgets Specification Discussion" group.
To post to this group, send email to opensocial-an...@googlegroups.com.

To unsubscribe from this group, send email to opensocial-and-gadg...@googlegroups.com.

[James Snell]

Just my $0.02, I would recommend moving away from the use of XSD and use Relax NG the way Atom did.

--

You received this message because you are subscribed to the Google Groups "OpenSocial and Gadgets Specification Discussion" group.
To post to this group, send email to opensocial-an...@googlegroups.com.

To unsubscribe from this group, send email to opensocial-and-gadg...@googlegroups.com.

[Jonathan Beri]

Interesting idea. At the very least we can offer an alternative definition.

[Paul Lindner]

I prefer the current proposal for all the reasons James mentions.

--

[Paul Lindner]

I'm positive on a RelaxNG schema if it makes it easier to validate
gadgets and build parser/generators.

Anyone willing to volunteer?

On Wed, Jan 26, 2011 at 9:49 AM, Jonathan Beri
<jonath...@magento.com> wrote:
> Interesting idea. At the very least we can offer an alternative definition.
>

> --
> You received this message because you are subscribed to the Google Groups
> "OpenSocial and Gadgets Specification Discussion" group.
> To post to this group, send email to
> opensocial-an...@googlegroups.com.
> To unsubscribe from this group, send email to
> opensocial-and-gadg...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en.
>

--

[goosemanjack]

I'm -1 on moving feature declarations down to the Content block for
several reasons.

1. Containers that don't support view-level features can't gracefully
degrade.
Adding the @views attribute to feature in the module prefs block
allows non-supporting containers to still supply the feature
globally.

2. Content blocks currently only contain rendered or data resolved
elements.
Adding feature declarations is akin to moving pre-configuration
directives
down lower into the executing code. The mental model doesn't pass
the
sniff test for me.

3. Multiple content blocks on the same view stream together.
Allowing feature require directives within content has the
possibility of
making the code less readable, not more readable. For example,
the
require directive could appear in the middle of the third "canvas"
block,
but should be applied to the entire content block execution

ex:

<Module>
<ModulePrefs>
<Require feature="opensocial-1.1" />
<Require feature="views" />
<Preload href="http://www.example.com" views="default"/>
</ModulePrefs>
<Content type="html" view="default, canvas">

<h1>First Content</h1>
</Content>
<Content type="html" view="home">
<h1>Home Content</h1>
</Content>
<Content type="html" view="canvas">
Rocks!

<Require feature="pubsub-2"/>
<Require feature="tabs"/>

</Content>
<Content type="html" view="home">
The party!
<tabset><tab>One</tab><tab>Two</tab></tabset>
</Content>

</Module>

[Andrew Davis]

-1 with goosemanjack, James and Matt.

Conceptually keeping the feature tags in the top of the gadget definition keeps all the elements contributing to the meta-data request in the same place.

As we look at extending the soon to exist container spec, and features start including parameters that extend the meta data, being able to efficiently process and batch the feature params so the container can preload the meta data.

We have a shindig patch we hope to get out soon that fixes feature params to come down in the meta request.

--Andrew

[Mark W.]

Actually,
Now that I've been reminded that we can have the separate CDATA section, and the other reasons Chris, James, et al have pointed out, I'm -1 as well.

[Randy Hudson]

This seems like a slippery slope. Will we eventually allow everything
to be scoped to specific views? Currently, containers include every
userPref value, every localized messagebundle entry, etc., when
rendering a view.

If views don't necessarily have the same features, this would seem to
imply that changing views will always reload the gadget. I was hoping
things would go in the other direction. We have gadgets today which
would be able to transition from "profile" to "canvas" views simply by
being resized. It's unfortunate that containers destroy and re-render
such gadgets just to "maximize" them.

[Mark W.]

I *think* some of the reason that a rerender is call is made to the server is the potential context switch, e.g. I can change users when the gadget changes views. One of the motivating factors for view level features is the case for mobile devices. The objective is that you could have a view specifically tailored for a device that does not load specific javascript libraries, e.g. dojo. Given this is one of the primary motivators, can you think of another way to address this. I think you raise a good point on the message bundles etc...

[Randy Hudson]

On Feb 2, 8:59 am, "Mark W." <weitzelm.w...@gmail.com> wrote:
> I *think* some of the reason that a rerender is call is made to the server
> is the potential context switch, e.g. I can change users when the gadget

I'm not familiar with the user-change scenario. I thought the most
common "view" transition was when a user asks to "zoom in" on a
gadget.

> changes views. One of the motivating factors for view level features is the
> case for mobile devices. The objective is that you could have a view
> specifically tailored for a device that does not load specific javascript
> libraries, e.g. dojo. Given this is one of the primary motivators, can you
> think of another way to address this. I think you raise a good point on the
> message bundles etc...

I understand the mobile scenario, but are gadgets really requesting to
transition between mobile and non-mobile views?

Maybe another way to support different "incarnations" of a gadget
(mobile vs. desktop) would be manifests. It seems like manifests are
the only option that allow containers to negotiate among multiple
implementations of a gadget, based on the version of OS supported by
the container. Wouldn't that solution also work for negotiating the
implementation based on the profile (mobile/desktop), or do we really
need two solutions?

[Tim Wintle]

On Wed, 2011-02-02 at 10:39 -0800, Randy Hudson wrote:
> On Feb 2, 8:59 am, "Mark W." <weitzelm.w...@gmail.com> wrote:
> > I *think* some of the reason that a rerender is call is made to the server
> > is the potential context switch, e.g. I can change users when the gadget
>
> I'm not familiar with the user-change scenario. I thought the most
> common "view" transition was when a user asks to "zoom in" on a
> gadget.

Almost all of the gadgets I work with have canvas and home views - the
home view being a very small efficient summary of the canvas view.

view level features appeal to me because the developers can keep adding
functionality to the canvas view while not affecting the file size of
the home view.

The transition between the two displays is (to me) completely different
from "zooming in", as there will be different (slower) data requests, a
much larger range of data, and a completely different layout on the
canvas view.

I agree with your point about message bundles and userprefs though, as
that data belongs to the application (gadget instance) rather than the
view on the gadget.

Tim Wintle

[Matthew Marum]

There is overlap, but I think there's value in allowing a simple mechanism to manage gadget resources without deploying multiple separate gadgets and maintaining a manifest.  Manifests, while desirable for many reasons, add more complexity.

[Randy Hudson]

We are using OpenSocial as the integration technology between our web-
based products. Customers must be able to upgrade one of our products
without upgrading all of them. If manifests do not solve the spec/
version negotiation problem, then we will be stuck forever using
OpenSocial 1.0. So manifests aren't just desirable, they are a
prerequisite for any of our products wishing to transition from 1.0 to
something newer.

[Andy Smith]

I could see where an application developer may simply treat a change
in views as a zoom mechanism, however, there are others that treat
views as different perspectives of that application that limit
functionality, required features, etc. In the case where a container
wants to maximize a view, do you need a different "view" for that?
If it's just simply maximizing the existing rendered content, perhaps
that's just a resizing function of the container. There are other
advantages to having a single gadget specification for both mobile and
other non mobile views as well. Some OpenSocial containers support
the life cycle events and application sharing (requestShareApp). This
allows an application developer to enable mobile users of their
application to share the same gadget with other users in the system
independent of mobile or other clients. This also makes it a little
easier to track an application as it moves across the social graph
through life cycle events.

[Randy Hudson]

> There are other
> advantages to having a single gadget specification for both mobile and
> other non mobile views as well. Some OpenSocial containers support
> the life cycle events and application sharing (requestShareApp). This
> allows an application developer to enable mobile users of their
> application to share the same gadget with other users in the system
> independent of mobile or other clients.

You can't have a single gadget specification, regardless of what the
solution for mobile and non-mobile is. The thing that people share
would be the application manifest. That would be the public URL for
the "gadget", not the URL for one of its entries, which would be a
gadget module specification for a specific version of opensocial, and
potentially for a certain device profile (i.e. mobile).

[Mark W.]

I'm not so sure I agree with your assertion that you can't have a single gadget.xml file.

For example, why couldn't you have this:

<?xml version="1.0" encoding="UTF-8"?>

<Module>

  <ModulePrefs title="OpenSocial App"

               author="Mark Weitzel">

    <Require feature="dynamic-height" />

    <Require feature="jive-core-v2" />

    <Require feature="opensocial-1.0"/>

    <Require feature="osapi"/>

    <Require feature="settitle"/>

    <Require feature="views">

       view level feature stuff here

    </Require>

    <Require feature="jquery-1.4.2"/>

  </ModulePrefs>

  <Content view="home" href="http://someurl/home.html" />

  <Content view="canvas" href="http://someotherurl/canvas.html" />

  <Content view="mobilecanvas" href="http://mobileurl/canvas.html" />

</Module>

In this case, I can include whatever I'd like behind the home.html and it behaves, according to the spec, exactly like it would a cdata section. So I think you could have one gadget file that handles mobile, canvas, etc... esp. with view level features.

[Randy Hudson]

It's not possible for a single file to leverage all of the new feature
in 2.0 yet still function in a 1.0 container. I didn't understand
your example, but it's not worthwhile to point out one aspect of 2.0
which may degrade gracefully in a 1.0 container, when there are many
other things which cannot.

[goosemanjack]

I think what we're seeing in the view-level feature discussion and the
manifest discussion is a blending and muddying of the waters. In
trivial cases and examples once could solve both primary use cases
with either solution in isolation, but they really are satisfying two
different use cases.

+++ View-level features use cases +++
Primary use case: Allows gadget developer to optimize feature weight
(amount of supporting code sent) upon a render request.

Secondary use case: Allows gadget developer to request different
versions of the same feature in different view contexts


+++ Gadget Manifest use cases +++
Primary use case: Identify multiple source versions of gadget so
container can get code updates from single URL entry point.

Secondary use case: Allow gadget developers to author entire gadget
source files based on features available in a container.


Looking at the primary and secondary use cases, the overlap is in the
secondary use case, not the primary use case. IMHO we need both these
features in the spec.

@Mark, your example is just hiding the fact that multiple files are
being managed by linking to them as proxied content blocks. You're
also not solving the problem of running on containers with different
available feature sets or of deploying a single gadget to multiple
containers running at different spec versions.

[Yoichiro Tanaka]

Hi Paul,

Probably I can help about it because I'm translating the gadget's XML
Schema to a Relax NG schema definition now. Please give me a few days.

Thanks,
-Yoichiro

--
Yoichiro Tanaka
Email: yoic...@eisbahn.jp
Blog: http://www.eisbahn.jp/yoichiro

[Mark W.]

Chris,

I don't think that the secondary use case for view level features is valid. Possible, but not valid. I think that goes to Randy's point of things don't gracefully degrade--you are either a 1.x gadget or a 2.x gadget.

I don't know how many app/gadget developers have come across the first issue. I think in reality, because we need to improve interop, that the secondary use case for manifests is the way things work right now--especially when you throw in container specific extensions.

I'd much rather focus on interop and standardizing differences than introducing more complexity to containers.

[Randy Hudson]

> In
> trivial cases and examples once could solve both primary use cases
> with either solution in isolation, but they really are satisfying two
> different use cases.

Agreed, we shouldn't focus on simple scenarios. Even though they stem
from two different problems, I still think the manifest proposal is:

A) the more critical issue. Manifests aren't primarily for
optimization. They are critical to moving forward. If I want to
deploy gadget support for some new feature (perhaps "opensocial-2.0"),
I am stuck today. I either break every container that is using my
gadget but doesn't yet support this new feature, or I introduce a new
URL to the 2.0 version of my gadget. Now when containers upgrade,
their users are still pointing to the old URL which doesn't leverage
said feature.

B) the only solution potentially solving both problems. The VLF
proposal completely fails to address the "runtime environment" issue.
Gadget providers need a way to provide two different implementations
of the exact SAME view (i.e. "profile" view). If the concern about
"weight" is divided primarily along the lines of the device profile,
then manifests could easily address that concern by adding another
attribute to the manifest's entries.

C) actually part of the OpenSocial 0.9 Specification. Although is was
pointed in the wrong direction (Instead of describing versions of the
OS spec, it was about versions of the gadget, something which would
mean very little to containers), manifests were previously in the
spec. They disappeared in 1.0, I suspect because they addressing the
wrong issue.

> +++ Gadget Manifest use cases +++
> Primary use case:  Identify multiple source versions of gadget so
> container can get code updates from single URL entry point.

That sounds right, but to clarify, the versions of the gadget have to
be automatically chosen by the container. So, unlike 0.9 manifests,
the gadget "versions" have to be labeled using attributes that are
meaningful to containers, not gadget developers. Maybe this is what
you meant by the secondary use case?

[rbaxter85]

Randy, we were also talking about "versioning" gadgets in this
thread: http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread/thread/299c75c1c2534c65.
However we could not come up with a simple solution. The more I think
about it though we do want something like a manifest, but I don't want
to bring that discussion into this thread.

[Yoichiro Tanaka]

Hi Paul and there,

I have just completed a creating the schema definition with Relax NG.
Some simple tests against it using Jing were also done (may not be
entirety). Each specified data type are same as an original definition
written by XML Schema in the meantime.

The created schema definition file using Relax NG can be downloaded at
an URL below. Currently, it is put on my web server.

http://www.eisbahn.jp/opensocial/gadget.rng

The definition above was created based on an original definition with
XML Schema written on a site below. I would be great to let me know a
latest definition if the original definition has already been old.

http://opensocial-resources.googlecode.com/svn/spec/1.1/Core-Gadget.xml#GadgetXmlSchema

Thanks,
-Yoichiro

[Yoichiro Tanaka]

Hi folks,

I have also completed a writing of a message bundle schema definition
written by Relax NG, and have created a patch file for a
Core-Gadget.xml. If these files can bring new value to OpenSocial
v2.0, could anyone accept and apply them?

Thanks,
-Yoichiro

[Yoichiro Tanaka]

Hi folks,

Files I sent as last mail were written by Relax NG syntax. I have just
converted these files to a Relax NG compact syntax, therefore I would
like to share them here. I think that we should apply them written by
the complex syntax.

I'm sorry about my consecutive posts...

Thanks,
-Yoichiro

[Matthew Marum]

I've updated Issue 1142 and attached a patch which we are using to track changes to the XSD for OS 2.0.

 http://code.google.com/p/opensocial-resources/issues/detail?id=1142

It fixes a handful of problems in the Gadget XSD that I saw.  It also includes a change to clarify the usage of the XSDs.  In Section 3.2 (http://opensocial-resources.googlecode.com/svn/spec/2.0/Core-Gadget.xml#Parsing) of the Core Gadget spec, it states that "The XML MUST conform to" the XSDs.  Shindig doesn't use the XSDs for validation and I don't get the sense anybody else is interested in doing that.  So I've changed the wording of the section to state that the XSDs are a reference.

[Matthew Marum]

I noticed after returning to this thread that Yoichiro had converted the Core Gadget XSDs into RelaxNG format.

How do people feel about dropping XSD in favor of RelaxNG?  I can migrate my changes into Yoichiro's patch if that's the way we want to go.

[James Snell]

While I haven't taken a look at the patch, I much prefer RelaxNG in general. 

On Mon, Mar 28, 2011 at 11:12 AM, Matthew Marum <mgm...@gmail.com> wrote:

I noticed after returning to this thread that Yoichiro had converted the Core Gadget XSDs into RelaxNG format.

How do people feel about dropping XSD in favor of RelaxNG?  I can migrate my changes into Yoichiro's patch if that's the way we want to go.

--

[Yoichiro Tanaka]

RelaxNG is simpler than XML Schema, at least for our specification. I
much prefer RelaxNG, too.

-Yoichiro

--