WEMI Face-to-Face Meeting3 April 2012Copenhagen

AttendeesPhilipp Bärfuss, Magnolia International Ltd.Jay Batson, Acquia, Inc.Arje Cahn, Hippo B.V.Alex de Groot, Sitecore Corporation A/SErik de Voogd, SDLAte Douma, Hippo B.V.Karsten Eberding, IndividualDavina Erasmus, SDLJames Falkner, Liferay, Inc.Daniel Hinderink, TYPO3 AssociationSerge Huber, Jahia Solutions Group SACedric Huesler, Adobe Systems (Chair)Paul Kelly, TERMINALFOUR Solutions Ltd.Boris Kraft, Magnolia International Ltd.Lars Nielsen, Sitecore Corporation A/SDavid Nuescheler, Adobe SystemsPeeter Piegaze, Adobe Systems (Secretary)Boyan Rabchev, TelerikThomas Sigdestad, EnonicJørund Vier Skriubakken, EnonicMartijn van Berkum, GX SoftwareFrank van Lankvelt, Hippo B.V. (Secretary)Shaun Walker, DotNetNuke Corporation

MinutesCedric: Introductory remarks.

Introductions all around.

Cedric: I had discussions with Gartner and Forrester. I asked what they think we should do. Steven said: “Why are you doing this”. He was skeptical. So we need to nail down the use cases. Mick said you should add this that and the other thing. But I think we need to focus on the basics, in terms of a building block. I urge you to keep this in mind.

Onscreen:

Our goals:

- Define a simple domain model for WEMI

Use cases:- display and mashup- index content and metadata- export all content/migration

Out of scope:- entitlement and access control- versioning and ecords management- data ingestion/ write operations

James: I saw the CQ demo with the client context. How interested is this group in having opaque extension points to do such things? Keep in mind if you have too many it destroys the usefulness of the spec.

Cedric: The client context is just extra metadata about who we assume is on the website. And figuring out that is another thing, not related to this spec.

David: It’s great to leave the door open for extensions. There are a few ways, like specify extension points. But if we are shooting for interoperability, we should remain more focussed. There might be value in defining terminology through our domain model. But, for example, when it comes to technical aspects of access control I would keep away from that. But in this case we can define that there is such a thing as “context” but I would not put it in the bindings.

Ate: But it is two different things. Access control and context. But I think the context is pretty central.

James: So, entitlement/access control is still out of scope but the context is different.

Jay: Whenever we migrate we need to think about A/C

David: But access control is so complex I don’t want this group to go into that because it’s so complex , it can be so expressive. So I think access control is out of scope.

James: The payload associated with the content is fine, but it would be opaque to this standard.

Jay: That’s fine.

David: And that’s true for other metadata, for example versioning. And often the messiest part is on authoring.

Jay: Ok, why are we doing this? Standards that actually solve a problem are good. Things that feel good are a waste of time. Parts of the iCal protocol turned out not to be useful, for example.

All: Some discussion and agreement on allowing extension points. SMTP “X-dash” used as an example.

David: I think the focussed set of use cases are things that really happen. I think mashup, display, index, expose and export are all real and useful.

Davina: I don’t think mashup works between WCMS’s. That doesn’t really happen. We are usually pulling content from other sources.

David: But sometimes our customers who want to build something to pull our content. Portals for example. But you are right this is not for interoperability between WCMS’s.

Boris: What would help is to look at what use cases are not served.

Alex: The things we list here are all solved individually: RSS, AtomPub, Google, etc.

James: But these don’t really have everything we need. AtomPub, for example, is not enough.

David: For me it’s the domain model that is valuable. What is a page? What is a site? These things are not dealt with by the more general systems like Atom.

Thomas: If you have a common vocabulary, then interop is easier to make happen. We would like to make this sufficiently high level so that this would be possible.

Ate: It might also be useful for other standards to make use of this vocabulary also. The user is the rendering director who does the aggregation.

Thomas: In the three cases we have: Export is a definitely useful. Indexing...of course we all have to export things to Google. But the first one is the harder one to figure out.

Cedric: The display part should not ignored. There is still a lot of scope for defining the plumbing. That might not be between WCMS’s, but it is a common problem that customers have. This makes it valuable. It could be as simple as a javascript UI that does a simple mashup. Sort of like Atom but Atom is about “channel”, whereas here we have the notion of “page” which makes up a hierarchy, so a new approach is still valuable.

Serge: That is interesting. What I really want to avoid is the complicated nature of CMIS, dual protocol, etc. It needs to be simpler.

Boris: About outcomes: Can we agree that we want to achieve? It is not about WCMS interoperability. It’s about integrating with third party sources.

James: Should it be possible to write a WEMI browser?

David: Yes.

Boris: As long as there is a business case.

Thomas: I think it should be as simple as possible. Just JSON and URIs.

Jay: I think page is too big for example.

Arje: So when we say “display and mashup content”, are we talking about us doing it or us offering it to some other system to do the display? It would be better to say we are offering something to other systems.

Davina: Ok, what is we say instead, “exposing content for display and mashup”?

David: I could see a URI like “/best-content-for-this-user”. This is not a repository API, we already have that. So, we talked about page, but now we get to start talking about the things smaller than the page.

Jay: For me content migration is the most important. For me, when I get customer asking to get stuff out of my system, as long as we can give them an API, they’re happy.

James: I am not sure. We are moving into more of an ecosystem. So for me the read/mashup is the important part.

Jay: Of course if we do this right, all of these should end up being “the same”. As for process: I suggest an IETF approach “rough consensus and running code beats principle”.

David: Yes, that’s good. I am a big believer in rough consensus. Usually this works. I would also like to see that we have a schedule that we try to stick too. This can help forge the consensus.

Jay: I would modify that a bit. It is useful to have a period of time for ferment. To allow some time to bubble, then we can start declaring a schedule.

David: Sure, I agree.

Serge: My preference is for a framework that would give you the basic building blocks. I am skeptical of interoperability. But I would like to make things a bit less abstract before we “ferment” things.

Alex: For the process. How can we ensure that we keep the quality? Like making it lightweight. How can we ensure this?

Jay: To a certain degree that is just good standards design. SMTP, for example, left space for experimental new features by providing the “X-” header. For us we might say: Here is the notation and here is how we can add new parameters. Start with simple and lightweight, and allow extensions. We did too much work in iCal. There are things that no one uses.

Arje: So far we have an empty standard...with extensions!

General hilarity all around.

James: So, the display and mashup. Is that JSON or HTML?

David: Both, I would say.

So, I think we are good on the general discussion, level setting, etc. I think it’s fine that everyone has a different emphasis on which of those three aspects are important. That’s totally okay.

Serge: Will we have to have a “reference implementation”?

Cedric: It’s not required by OASIS, but it is in our interests to write a reference implementation and test suite.

Describes the OASIS process about the document, draft etc.

Daniel: I think it would be very helpful to develop a validator service, much like W3C provides for testing compliance with the standard. This would help to push adoption, because testing would then be available to clients and developers in our community, without having to set up testing environments individually.

David: As for somewhere to host this. I recommend we use something like Apache. We could hijack a project. We wouldn’t even need a separate project. We could use Chemistry or Jackrabbit.

Jay: I would recommend LGPL.

David: Is the Apache license for this okay?

Jay: Yeah, I am not worried about it.

Cedric: There is only one date mentioned so far: Sept 2012: deliver domain model and http binding. So is this going to be “the standard”?. Will this be “our work” and then it takes the OASIS system a while to make it into a standard?

Alex: I am a bit concerned about doing it over the summer. Is that okay?

Daniel: For us that’s okay since we could make it part of our Summer of Code thing.

James: May I suggest that by the end of today our goal is to have a set of URLs as an example set of what you could do with a WEMI system.

David: More specific use cases.

James: Yes, a representative set of URLS.

Serge: And examples too.

Agreed all around.

Arje: Since we all use different technology we might have multiple language implementations.

Cedric: Yes, we might want to focus on one first. But the examples will be independent of the implementation technology.

So someone asked, ”Why do we not vote?” The reason is that under OASIS every TC member must have the opportunity to vote. So we have to do votes on the mailing list, not just in the room here.

Let’s start now with the domain model and come up with some examples for URLs and what output of that URL would look like.

We started with the page. But it is too big. So I will write down some terms and see if we can come to some understanding:

So for example, the page: It has a URl (though it is not the only thing that has a URL) and it has content inside.

Shaun: This is very desktop. What about mobile?

Davina: But that is okay. Page can be a desktop concept.

Cedric: A page is certainly a container of other units. These are the terms we need to define in the domain model.

David: I would prefer less generic terms than view, resource, etc. I prefer something more like page.

Boris: I prefer even more semantically precise terms: like article, homepage, etc.

Davina: The page represents a number of relationships that get lost if we just talk about a “piece” of content and we need that specific metadata, that relationship information.

Boris: Are we trying to describe every possible type of content or do we want to come up with a list of basic concepts?

David: I think we have to ask ourselves, “What do we talk to our customers about?”, “What are the entities we talk about?”.

General brainstorm produces a raw list:

pagetree/sitemapimagetextarticleusercontentblocks paragraphfieldregionpartreferenceactivitywidgetsentryfolderrenditiontemplatescontextformscomponentmedia assettagtaxonomybody

Someone: But aren’t there a lot taxonomies out there already?

David: Yeah but I don’t think there is a common vocabulary.

Cedric: Maybe someplace like W3C might already have some definitions?

Arje: So we now have this list. Can we pick three?

David: Ok maybe we can each pick three and see what each comes up with.

James: We could try to align these elements with the terminology of HTML: like header, footer, article.

Boris: The core of the page is what you really want when you import. For example, the header and footer are typically the same for all pages.

Jay: It is slightly irrelevant to have a tree. What we really want is a list of content in your system and what are the urls you use to get at them.

David: Yeah, a sitemap is list of pages. The question is, “Is the hierarchy of the sitemap common enough?”

Davina: On the management side the tree is important. On the delivery side it is not so needed since sitemaps become less important as sites are more dynamic.

David: Yes, and since we need to support export, we want to be able to do that for the sake of management.

Jay: Why don’t we just use the html5 vocab for everything within a page?

David: I use sitemap in the sense that Google uses it.

Jay: So, let’s get rid of “tree”.

David: Okay.

Jay: Page is fine. Sitemap is fine. The important stuff is inside the page: The article, section, etc.

David: So can we say sitemap contains pages that consist of articles and sections that refer to assets etc. and we can use HTML5 “aside” too?

Jay: So we can use the HTML5 terms, that’s fine.

Alex: And all of these things are sections.

On screen (approximately):

[sitemap] (list of pages with optional hierarchy)

contains [page]* contains [section]* which can be of types [article] [aside] etc.

Davina: So, how do we access these subelements? Through the page?

Cedric: Good question.

Erik: You might not have access to the page. You might only be able to get to the article directly, not through the page.

Cedric: I would like to see a very direct selection of a small part of the content. Instead of getting the whole page.

Ate: So this raises the question of how much the context of an aside influences the meaning of the aside.

Davina: That depends on the final presentation and thats up to the consumer of WEMI. So the question is whether we expose these subelements in the sitemap.

Jay: Is it likely that asides would be used directly, by themselves?

Davina: Yes, a site might display banners from some other source.

Ate: If you access a certain article through a page you are providing a lot of context. So if you tell me that you went through this page X that gives me a lot of info. So everything should have a URL.

David: So, every section, asset, sitemap is a resource and therefore has (or can have) a URL.

Thomas: What is the relation between these terms and part and region?

Someone: These are all sections and sections can have sections. Davina: And it does make sense to choose one term.

Cedric: To use portlet as an example, the output of a portlet could be a section.

James: Are the leaves also sections? Or are their other types of subelements?

David: Could we say we have nested sections?

Ate: Yes, and that’s up to the provider. And the customer can drill down. Do we want an explicit leaf?

David: I don’t think there is a need for an explicit leaf.

Cedric: So how do we represent what is inside an article? article.html makes sense, but what about article.json? What do we return then? We want to have some semantics below that.

Thomas: Might we make it seem like all HTML sections are individually requested?

David, Ate: We can just specify that not all html sections are necessarily wemi sections.

Alex: From an external point of view, the section idea is extensible.

Boris: Basically are we saying that we can’t guarantee what we return?

Jay: We are rehashing what W3C did anyway. The definition of section in HTML5 sounds like what we mean.

Cedric: Firstly we are only using HTML terms, but it doesn’t mean that everything section in WEMI corresponds to a literal section in HTML layout.

Thomas: [Describes the page model on his product] Each subject can be individually addressed.

Jay: The note in the section definition of HTML5 says that a section is used for specifically addressable and findable content in the sitemap. So you only call something a “section” if it makes sense to get it with a URL. Other stuff would just be a div.

Boris: Does the system that requests the information know what this information is?

Davina: When it becomes interesting is when the information inside says things like: “this is for mobile, this is for desktop”.

Ate: For indexing, for example, you might not need to request the whole content. Maybe you only need to retrieve the sitemap. Cedric: So what about the discoverability of what is there. What is the content going to be when you access it as JSON. Maybe that gives you what is inside the page that is directly addressable. So, for display you have one set of stuff you want to get. But for indexing you might want some other subset, same for export. But we don’t define what is relevant or not.

Thomas: With respect to indexing, you can already use microdata. So what are we adding on top of that? Maybe we only need to add a URL: Go here if you want the core data of this page or whatever.

Cedric: So how would you represent article.json, including the microdata? Do we expect a certain number of fields defined by the spec?

James: For export we need to expose everything.

Serge: Actually the HTML cache manifest looks a lot like the sitemap.

David: It’s a different use case. The cache manifest is for offline browser support. For our export we need more semantic info. I think the cache manifest is too flat. It’s more resource related.

James: Maybe there is another more complex JSON representation. I would expect something like article would have title, description, etc. Which are all defined.

David: I think the page.json is the same as the page map.

Ate: I think the page.json would include all the content, while the page map doesn’t include content all the way to the bottom.

David: Maybe sometimes you want inline all in one just a stream of HTML, while other times you might want to have it sliced and diced in the hierarchy.

Ate: There are both cases.

Lars: I think there should be a switch: content inline vs references.

David: What is the default behavior you want?

Lars: You might want the content in one case.

David: To me the JSON is the data and the HTML is more the snapshot of what it looks like.

Ate: I can see using the JSON for the outline and the HTML for the content blobs.

Shaun: So, if I make a URL with page X and section Y, what do I get back? Let’s say I get it as JSON.

Davina: References.

Shaun: What happens when I want the HTML version?

Ate: A lot don’t have anything except HTML.

David: If you think of the indexing use case. Let’s say Google wants to use this information (the JSON). The issue is the customers are not happy to share that metadata info that they need for export with the general public.

James: They can just turn WEMI off.

Alex: Also for example, if it could be the input to a screen reader, for example, that could add value.

Ate: So we need to think about a WEMI compliant site vs a WEMI compliant CMS.

James: We are hoping to use WEMI to export from some version and import into the next version. But in a version agnostic format.

Davina: If our customers have a standard, it makes it easier.

Frank: Do we want to support query parameters?

David: It is always very tempting to descibe a URL structure. I think it is enough to have an entry point to a sitemap and just have the hypermedia links from there. I am almost tempted to say that we give complete freedom to the URL space.

Thomas: What about the HTTP header?

David: I would never touch anything in the header. And you can’t get to header from Javascript.

So my question is do we want to specify some kind of URL space, at least in a best practice way, for example, the .html, and .json endings?

But that’s not RESTful. But that’s ok, we don’t need to observe the hypermedia constraint of REST.

We can keep it open whether we want a URL structure defined.

Alex: And what about putting the WEMI version in the URl?

David: We did that with namespaces in JCR and it was a bad idea. So I don’t want to do that. We can version the spec but not use it in the URL.

Cedric: Ok we still havent talked about what’s going to be inside the json. So lets start the process: So let’s say you request

/sitemap.json entry type:page, section, sitemap url:/iphone/features/siri lastmod:zz

David: Are the sections in the sitemap or are they not?

Davina: I don’t think you should need to get the page to get a sections.

James: We could say these are the entry points and these are normally the pages.

David: Would you say everything that is referenceable is in the sitemap?

Davina: Yes it should list it all. You might find a section through a page...

David: Does the section need to be in the sitemap? Must all sections be in the sitemap? Sometimes I might not have a place for those in a sitemap. The more we stick in to the sitemap the more volatile it becomes and changes every second. So I prefer not to force all sections into the sitemap.

James: Maybe its up to the builder of the sitemap.

Davina: Do we want to give sections an attribute that makes them sitemap-required and some just discoverable.

David: We don’t have the idea of attribute yet...

Ate: So maybe if you have reference, fine. If not, just make it discoverable through page.

David: Is a page a section? If it is we can say sitemap is a hierachy of sections.

Ate: And we can have a sitemap point to another sitemap.

Davina: What if we specify that everything goes through page and then a few years go by and that page disappears. I should be able to hang those sections in the sitemap if I want to.

Boris: You might have building blocks of your site that primarily exist outside your page structure and you want to be able to expose these through WEMI.

Davina: We can also think of a booking system and the website, and they both need to access the same “section” or “component”.

James: Maybe the top type is resource and subtypes are page, section, asset etc.

David: Which use case does this address?

James: Then I can add everything accessible to the sitemap.

Shaun: Using HTML5 is tempting. But is that what we want? There are other non-browser renderables that we want to access.

James: That’s my problem with that. The HTML5 terminology seem to suggest that it defines how to composite the page, whereas we want to describe how to composite the site.

David: I think we reached a good point already. I think we are more aligned on so many things. Maybe we can take another look at the more detailed structure.

Cedric: And we can talk about the type names. Ate: Thinking about the sitemap. The separation of pages and section as standalone idea. I have another idea: You could instead have the distinction of canonical page vs some other page presentations. But it’s still a page.

Alex: It could be the case that a section has its own URL but it is hard to find the case where a section is really something different from a page.

Ate: And a canonical page might never show up.

Davina: We could say that everything referenceable is a “page”.

Ate: Yes, a section could be a minimalistic page.

Davina: The problem is, to me the word “page” has meaning as the thing that contains these other elements. It comes down to the question of the granularity? Field level? Section level?

Ate: I like the simplicity of just one type.

Cedric: The question is do we need a new type. We only need a type if the treatment is going to be different.

Boris: One of the advantages of this effort is to not be too abstract.

Cedric: So the type aspect can be used to show what is possible: get a page, get a section etc etc.

But right now I’d like to go down a bit more into the json format: what would you get?

page/section.html → fully rendered page/section

James: So, if you request a subsection do you get the item as it would appear if you got the full page. And another question is WEMI for the browser.

Jay: Yes. Fully styled or just raw content depending on the json request.

Ate: we could make an API requirement that it can deliver as a “html fragment” (canonical) vs as a “full html document”.

Lars: So the fragment would work when you request it in the context of a page.

Karsten Eberding: What about parameter in the URL?

Cedric: They would be listed in the sitemap with those parameters as required so that the content appears as desired.

Boris: Do we want to look at this in the context of pages or a more generic way? For example, give me all your assets, all your images.

Cedric: But that is just whatever comes up in your sitemap.

Boris: Maybe or maybe you have a different standard name like assets.json.

Thomas: How do we know how we can break down a page?

Cedric: That could be discovered in sitemap.

Thomas: But there can be more stuff than that. For example, an image in a different repository.

James: Maybe the JSON definition can tell you what the subparts are.

Cedric: So, what does the JSON page look like?

James: For dynamic content like a portlet it could be the configuration of the portlet.

Someone: What about query?

Cedric: The sitemap would be whatever the result of your search is. It might not be a full sitemap. It could be whatever is coming from the query.

Jay: [Shows the my.FCC.gov site: Each widget runs off a query]

Cedric: But I do see the advantages of query.

Davina: We would just use a hypermedia navigation.

[Some discussion of standards like OData and GData]

Cedric: In OData they use discoverable schemas that you discover through hypermedia and then use to interpret the further results of your JSON.

James: We could have a generic metadata object in which we have some standard properties like type, so that we don’t mix up our “type” vs. “type” coming from the read content.

Jay: Perhaps we can go home and do some research and find out if someone has already figured out the “JSON” content format. We should not reinvent the wheel. So what are the level things that we want to discover?

Alex:: We have focussed on HTML and JSON, But I can imagine other cases where another format might be useful. Maybe Atom or whatever. I see these as different views on the same data.

Cedric: So maybe the HTML could be whatever the “native” represntation is (pdf?) so that could be in the sitemap too.

James: A question about OData. How do they handle this?

Erik: Perhaps we could get by with defining the domain model and then use OData or GData.

Cedric: You could argue that GData and OData are quite similar to what we are trying to do here. But they seem much more rigid. They are purely about data exchange.

Boris: Two things we should do: First, go back to the use cases (the three) and figure out the exact problem in each case. Second, for this group, if we could leave today with an idea of what we could do: we should try to find something that is exciting. For example, I like Jay’s query API. I think it would be great.

Jay: I’d like to walk out of here knowing a way to discover how to name content: its fields and structure, and ask for it and then do something with it.

Boris: Being able to query another system for “all press releases” something semantically meaningful, that is interesting to me.

Cedric:Ok, back to the use cases:

Display and mashup

- sitemaps to discover content- query content e.g. give me all articles from last month- getting the content (rendition / raw data)- providing a context

Boris: Taking inventory is a good example, with the query system. For example: “give me all the images”.

Alex: Or would inventory be about getting information about all images?

[On screen]

%page.json- lastmodified- section - name = section1 - url = %page/%section - section - name = section1a - key = value - key = value

Thomas: Maybe we could have the server give back some context as well.

Lars: Would you not rather query with your context and then get a sitemap back?

Cedric: That is interesting. We could assume an opaque context key value set. How would we send that along? The only way to do it through javascript is set a cookie. What would the format be? But we cannot define how to react to these things.

Alex: Can we look at existing analytics vendors for how they do it?

Cedric: We can’t define all that. The most we can do is to define how to pass these contexts from consumer to producer. Whoever requests the content says I request the content with a certain context and the server figures out how to do that...so we can define how this info is sent but not what the info actually is.

So what can we say what makes wemi different from AtomPub: Context sending like this could be one of these things.

Export would be a “no context” request, perhaps.

Ate: I would have different endpoints for different contexts. To me a context is a kind of query and it returns a sitemap that might be a set of unique endpoints.

Besides cookies, what other ways are there to transmit the context?

Artje: I would not want to specify that we use cookie, in particular

Lars: We could set the context and get a token and the next time send the same token.

[Discussion about context format]

Cedric: Something we haven’t discussed is discovery of possible contexts.

Lars: We can’t really do that.

James: We could have the content token be opaque to the spec but there is a well known field. We define where to read the field from.

Cedric: [Summarizes what we did today]

Perhaps we can split up some of the discussions we have had, and make up some examples for each one.

We also need to define what happens when someone doesn’t have authority to do something. Since it’s a not a human using this interface. For example, perhaps without authority the link does not show up at all...you can’t even get to a forbidden URL, and even if you guess it you get 404, not an authorization requested. This avoids the http :// foo . com / ceo - fired . html problem.

Or we could say that at any point you might get an HTTP authorization request and you have to be prepared for that.

Are there any constraints we want to look at what we return in the JSON view? Should we only give back exactly what is requested or a full dump? One might want the specific field you requested.

Jay: I think the most common case is that the person already knows the schema of the returned data, because the people using these service APIs are going to be programmers who likely can dig into the structure of the data they want. So they’ll know what to ask for - as long as they can determine it somehow. We can leave room for more sophisticated things later.

Cedric: Any query format in mind?

Jay: Just a plain URL query format.

Cedric: [Discussion of tools and organization]

We can use wiki, mailing list etc.

James: And we need one person to hold the pen. And they can delegate.

Jay: So what tool for the intermediate documents? Google Docs?

James: We could create a document on the oasis site where we can all put our email and IM.

Cedric: [Summing up]

Most people see today as a good start. People want to organize subgroups. And assign tasks: domain model, individual use cases, etc.

Karsten: We need to discuss the distribution of tasks.

Jay: I think at least we need commitment to work together online. We are in the discovery time for this standard.

Lars: If we want this to be a success We also want to start to influence the big players and Forrester and Gartner, etc.

Jay: And we should re-use as much as possible.

Cedric: Sorting out some teams and task lists is the next step.

Jay: This will flow out of how we get things done in the next couple weeks. We will make a task list and then people can volunteer to the tasks they want.

[Suggests using the scrum method] We could make a three week sprint. It is a bit more heavyweight, but it gets results.

Alex: I think at the moment it would add a lot of overhead.

Ate: I think it’s a bit early for that kind of process. Maybe after we get past the discovery phase.

James: I’d like to see in the next call have some deliverables, especially the research part, like how should wemi be different from odata etc...

Cedric: I would recommend a call pretty soon. Next week. And present the minutes and tasks. Next week Wednesday 5pm CET.

For the next face-to-face f2f maybe June. After that we would have to wait until September.