SELECT * FROM Document WHERE dc:title = 'Some Report'

or:

SELECT * FROM Document WHERE dc:modified > DATE '2011-08-01'

or more complex:

SELECT * FROM Note WHERE dc:modified > TIMESTAMP '2011-08-01 12:43:38' AND ecm:fulltext = 'merger OR ipo' AND dc:lastContribtor IN ('bob', 'john') AND (m:priority BETWEEN 1 AND 5 OR m:level > 1000)

Of course you can mix all standard operators, add parentheses, OR, etc. More details about NXQL are available at http://doc.nuxeo.com/x/uItH.

But one limitation of NXQL used to be that, although Nuxeo can store and retrieve "deep" complex properties in its documents, there was no immediate way to use them in queries written in NXQL. We call complex properties those from documents described by an XML Schema that includes a <xs:simpleType> with a <xs:list>, or a <xs:complexType> with optionally a <xs:sequence>. Such schemas provide complex data modeling options to the developer, and are used a lot to store deeply structured objects in one document.

Starting with Nuxeo 5.4.3, the limitations on querying these complex schemas have been lifted, and you can now do queries on them!

Here are some sample queries that you could not make before Nuxeo 5.4.3, and are now possible:

The documents where the first subject is 'test':

SELECT * FROM Document WHERE dc:subjects/0 = 'test'

All the possible subjects starting with 'test':

SELECT DISTINCT dc:subjects/*1 FROM Document WHERE dc:subjects/*1 LIKE 'test%'

The files less that one KB:

SELECT * FROM File WHERE content/length < 1024

The files sorted by size:

SELECT * FROM File ORDER BY content/length DESC

The files with a given file name:

SELECT * FROM File WHERE content/name = 'report.doc'

The JPEG files, by filtering on the MIME type:

SELECT * FROM File WHERE content/mime-type = 'image/jpeg'

The documents where the first attached file is more than one KB:

SELECT * FROM Document WHERE files/0/length >= 1024

The documents with an attached text file and an attached file of length 0:

SELECT * FROM Document WHERE files/*/name LIKE '%.txt' AND files/*/length = 0

The documents with an attached file of type text and of length 0:

SELECT * FROM Document WHERE files/*1/name LIKE '%.txt' AND files/*1/length = 0

Note the difference, the second request needs to correlate the two file instances in the two clauses, which is why we use a special *n syntax to tell the query engine that this is the same one. The number after the * is arbitrary, but all the uses of files/*n with a given n will refer to the same file.

Using these new query capabilities, developers will now have full access to their data model from NXQL, and will no more have to drop to ad-hoc hibernate queries to do this kind of query.

One cautionary note to end this post: these NXQL queries are turned into SQL queries that use a number of JOIN operations, and the execution of such queries has its price if your database is not tuned correctly. Please note that just because you can make queries does not mean they will automatically be efficient, ensuring this is the job of a data architect and a DBA — this is true for any system, not just Nuxeo.

Before becoming a TLP, Chemistry was just an incubating project, guided in its growth by the Incubator, like all Apache projects when they begin life in the ASF. So what does the move to a TLP signify? Briefly:

• the project's scope is now clearly established,
• the community around it has been deemed large enough to sustain the project,
• a Project Management Committee (PMC) has been formed to make internal decisions,
• the PMC and other committers have become acquainted with the Apache Way of doing things,
• successful releases of the software have been done.

Now that Chemistry is a TLP, it means a number of things:

• the project has now top-level visibility, like all other Apache projects,
• it should be perceived as mature by other developers (even though we're not yet at 1.0),
• Chemistry will be able to decide by itself when to do new releases without oversight from the Incubator's PMC.

For Nuxeo this means that we are more confident than ever that our involvement in the development of Chemistry under the Apache umbrella was the right choice. Thanks to Chemistry our products have top-notch support for CMIS, and we know this will continue to be the case in the future.

Nuxeo has actually very little adherence to the Java EE spec. We use technologies like JPA, JSF or Servlets that are included in Java EE 6, but they predate it, so most containers already include them, and if not they can be used as simple libraries that are wildly available. We don't require EJBs, and we don't require JMS (although they can be used).

The only things we need really from Java EE that are usually not available outside of it are JTA (transaction management) and JCA (connector architecture with pooling and transactional support). And because we want Nuxeo to be able to run in non-Java EE containers, we have developed an optional module (called nuxeo-runtime-jtajca) providing the JTA and JCA infrastructure when needed. This module is based on code from the Apache Geronimo project.

The result is that, provided the necessary deployment features are there, we can run out of the box in:

• Full embedded (no container),
• OSGi,
• Jetty,
• Tomcat,
• JBoss,
• and more could be added.

The important part in the above is "provided the necessary deployment features are there". Because Nuxeo has a specific modular extension model not available in any spec (see our Component model overview), we need, for the Nuxeo Runtime to work, to plug into the container's startup and deployment model.

For each container we have to write a small container-specific piece of code to be able to control the deployment order of our JARs, scan them, analyze what extension points are present, and inject their configuration in the Nuxeo Runtime. This is implemented in modules like nuxeo-jboss-deployer, nuxeo-runtime-jetty-adapter, or nuxeo-runtime-tomcat-adapter.

If you would like Nuxeo to run in other containers (GlassFish v3, JBoss 6, WebLogic, WebSphere, JOnAS, etc.), the you should know that the work is not huge, and that our architecture team planned for it. It just needs a bit of time and manpower; you should contact me directly if you're interested in contracting us for this open source work.

In the meantime, you should really try Nuxeo under Tomcat (which is the platform we recommend for now).

Nuxeo used JCR in the past with great success; we've been on the JSR-170 and JSR-283 Expert Group and it is a very nice spec. Several versions of our Nuxeo EP framework used Jackrabbit as a content store.

However for some time we've decided to not rely on it solely, and for more than two years, since Nuxeo 5.1.6, we've had an alternative storage engine, the Nuxeo Visible Content Store (VCS) (http://doc.nuxeo.com/display/NXDOC/VCS+Architecture). Since Nuxeo 5.4 VCS is the only content store, and it's optimized for all the things we require of it.

The reason why we wanted an alternative storage, and why we now rely exclusively on it instead of maintaining costly compatibility with a second storage engine, is that Jackrabbit had a number of limitations:

1. Opacity of the in-database storage. We wanted data stored in a SQL database to be real SQL tables with visible data. This is helpful for many things, be it imports, backups, debugging, etc. While the goal of JCR to be the "SQL of content" is noble, the reality is that all our customers want data to be in a SQL database, not in something they don't know. We had had previously the same problem with Zope and its ZODB btw. Serializing Java objects in database columns is really not our idea of a clean storage.
2. Limitations of the relational model. We wanted to be able to express arbitrary relational queries between objects, and the Jackrabbit query implementation, based on Lucene, really didn't allow for that, or not with adequate performance (see point 3. below also). There was a lot of work trying to optimize that in Jackrabbit, but I only saw it as a futile exercise in reinventing SQL JOINs and the tens of years of work behind current implementations of the extremely intelligent planners and optimizers of successful SQL database engines.
3. Performance. There were also unresolved performance problems with nodes containing a huge number of children, inherent in Jackrabbit's way of storing children information. I haven't kept up with the latest Jackrabbit releases but at the time this was killing us, and there was no simple fix available.
4. Over-strict versioning model. The JCR versioning model is fixed by the spec, and does not allow for instance for small changes of metadata on versions that were very useful to us, like updates to the number of readers of a doc.
5. Needless dynamicity. An important credo of JCR is that you can have "free-form" content, and can add or remove properties to nodes anytime. While this is in theory a great idea, and may appeal to the WCM-inclined, it also has a large performance impact, and is really not something that any of our customers want in their databases. Customers want well-defined and fixed schema. DBAs want to know beforehand what the tables will look like. Now, Nuxeo VCS can of course add or remove fields in its schemas, but it's an administrative step, and is not done in the normal course of an application's life.

But the cinch really was the first point, a proper SQL representation. At the lower level the VCS architecture really resembles the JCR concepts of nodes and properties, but it stores them cleanly in tables (see the above URL for a description). For a time we considered overlaying a JCR API on top of it, but that has not proven necessary because there was little customer demand for it, and because we have a higher-level document abstraction that hides this anyway.

Now that CMIS is getting recognition, we believe it's a better way to expose a document store than the Java Content Repository API. We are on the CMIS Technical Committee, and we now have a CMIS interface on top of Nuxeo (http://doc.nuxeo.com/display/NXDOC/CMIS+for+Nuxeo), about which we're very happy.

Get your content under control with CMIS and Apache Chemistry

The CMIS standard provides an answer to most issues met by typical content-centric applications by offering a common model and a set of services for ECM interoperability. In this session we'll first provide an introduction to the CMIS services and bindings, then we'll offer a view of the landscape of the different ECM providers and clients implementing CMIS, and we'll finish with practical examples of the uses of OpenCMIS, the Apache Chemistry (Java) library, designed to help you easily write CMIS applications.

I hope to meet you there!

People from Open Text (our host for this week), SAP, Alfresco and Nuxeo were present. There were lively discussions about many technical points, but following the Apache rules of conduct for such meetings all points were summarized each day to the mailing-list for larger visibility and input by the whole community (see the archives here). The remaining work to do for this merge will be logged in the Apache JIRA issue tracker, again to provide visibility.

Once the current code base is stabilized, which we hope will take no more than one or two weeks, we want to make a first 0.1-incubating release, in order for clients to be able to start using a fixed version of the library. I will be the release manager for the first release, which will likely be the most complex one for us as we learn the ins and outs of releasing an Apache project.

Regarding naming, “Apache Chemistry” continues to be the global umbrella hosting CMIS-related projects at the Apache foundation. The particular Java sub-project providing a general-purpose library for the client and server side, that was the object of this merge, is named OpenCMIS in recognition of the origin of the majority of the code. Other sub-projects (a python library, a Javascript one, various other clients, etc.) will be encouraged to find their own name to have an easily remembered identity under Chemistry. The website will also soon be updated with more documentation about all the projects, including the new OpenCMIS.

At the moment Chemistry is still in incubation phase at Apache, but given that the community around it is now well established we hope to start the process of becoming a fully fledged top level Apache project soon.

Meanwhile the OASIS CMIS standard itself is now being voted upon by the 323 voting members of OASIS. If all goes well, by early May the vote will be complete and CMIS will be an official 1.0 standard. If your company or organization is an OASIS voting member (see http://www.oasis-open.org/about/ and http://www.oasis-open.org/about/contributors.php for a list), please urge your representative to vote for CMIS.

At Nuxeo, we’re in the process of switching our CMIS support from the Chemistry library to the OpenCMIS one. And of course this will be transparent to users of the CMIS API, that’s the whole point of having a standard Nuxeo will then be the first open source server whose CMIS support is implemented using the OpenCMIS library. Stay tuned for announcements of this release!

For more practical info on using CMIS in Nuxeo, including download links, see http://doc.nuxeo.org/xwiki/bin/view/Main/CMIS.

Note that our demo server at http://cmis.demo.nuxeo.org/ has been updated as well.

Below are most of the new features available since the last release.

Better search

Fulltext search with CONTAINS() has been implemented so that you can do queries like:

SELECT cmis:name FROM cmis:document WHERE CONTAINS(‘foobar’)

(The full scope of the fulltext search syntax, with ORing of words and negation, is not there yet.)

You can now also use the IN_TREE() and IN_FOLDER() predicates.

The SQL keywords are now case-insensitive as the spec requires, and complex boolean functions have been fixed.

More CRUD

A number of fundamental features form the CMIS domain model are now complete: object move, folder tree, folder descendants, delete, delete descendants.

Miscellaneous

Other fixes have been done: the types are served according to the latest 1.0CD06 draft, a number of fixes to make more CMIS clients happy have been included.

CMIS Shell

Finally, keep in mind that there is now an easy way to test a CMIS repository using a command line client. See the CMIS Shell blog post from Stéfane for more.

Basics

I will not detail here the basics of the CMIS domain model, but I will mention quickly for completeness:

• CMIS stores folders, documents and relationship (collectively called objects),
• each object has a unique id,
• objects have "object types" detailing the properties they're allowed to have,
• properties have the usual basic "property types" (strings, numbers, dates, lists, etc.),
• you can create, retrieve, update and delete objects (CRUD),
• documents may have an associated content stream (an attachment),
• you can search documents using a SQL-based language,
• clients talk to CMIS servers using AtomPub or SOAP.

Below I will detail the more advanced features of CMIS.

Unfiling, Multi-filing

While most people are used to storing documents inside a navigation tree, where the intermediate tree nodes are folders, there are other ways to deal with content, which CMIS exposes through the concepts of "unfiling" and "multi-filing" (the term "filing" expresses the idea that a document is stored in a place, much like in the real world).

The first alternative way of storing a document is to not file it anywhere: the document is not held in a folder, it just exists: it is then said to be unfiled. The document is not lost however, because given a document id you can retrieve the properties and content stream of the document, and if you don't know its id you can do a search based on relevant criteria to find your document.

This model of unfiled documents is quite common in the world of record management, where what is important is the "record" (the content and metadata), and not a folder in which it may live. The record itself carries all the metadata you need to find it (dates, keywords, tags, etc.), and instead of listing "what's in a given folder", you can list records according to simple or complex search criteria.

The second alternative way provided by CMIS to store a document is to allow it to live in several folders at the same time: this is called multi-filing. It's another way of organizing content, and can be quite powerful.

Multi-filing is often used to organize documents in folders along several axes, where a folder represents a criterion and the presence of a document in a folder reflects the fact that the criterion applies to the document. Multi-filing can also be used to express "publishing" concepts (publishing a document in several categories means just filing it in different folders, each folder representing a category).

Both of these features are optional in a CMIS repository.

Renditions

In content management systems, it's quite common for a document to have different renditions. A rendition is an alternate way of viewing or representing a master document. For instance from an OpenDocument file you may derive a PDF rendition, a 100×140 pixels image rendition of the cover page, a Microsoft Word rendition, a rendition as a series of high-resolution images for each page, an HTML rendition, a pure text rendition, an MP3 rendition of the content as spoken text, etc. From a video document you may get a H.264 rendition, a Flash rendition, a 64×64 pixels image rendition, a rendition as a series of 320×200 pixels images every 10 seconds of the video, an MP3 rendition of the audio stream, a pure text rendition of the speech extracted from that audio stream, a text rendition of the extracted subtitles, etc.

CMIS doesn't expose any way to create or control these renditions (it's too complex, and up to the content management system to decide what they are), but it exposes a way to discover and retrieve them. Documents and folders can both have renditions, each rendition being seen as an alternate content stream.

Renditions have rudimentary metadata, among which a MIME type, a width and height (recognizing that rendition are often visually oriented), a title, and a "kind" which is used to categorize the renditions. CMIS only defines one standard kind, the thumbnail, but more could be added in future versions of the specification. The fact that it's useful for a folder to have a thumbnail or an icon is the reason why folders are allowed to have renditions while they can't have a normal content stream.

Rendition support is optional (and in any case it's the repository that decides what renditions to expose for each object).

Versioning

In CMIS a document (if its type supports it) can be versioned, which means that "old" versions are retained by the system. A version can be "major" or not, but CMIS doesn't impose any semantics on this, it's just a useful abstraction. To create new versions, a model of checkin/checkout is used: after checkout from a version, a private working copy (PWC) is created, which can be modified and then checked back in, creating a new version.

Here the model gets complex because in the real world there are many ways in which versioning can be done.

In the most complete scenario, the repository allows read and write access to all versions, including the PWC, and allows all versions and the PWC to be searched. The versions can also be filed independently in the same (or different) folders, several versions being then accessible at the same time.

This model can be restricted by the CMIS repository in various ways. The repository can specify that:

• only the latest version may be accessible or searchable, not the older versions nor the PWC,
• a PWC may be checked out from only the latest version,
• a PWC may not be updatable at all, only checked back in with some modifications in a single operation,
• a checkout may not be allowed at all, in which case new versions may be created only by applying an update to an existing version; this leaves the existing version unchanged but creates a new version holding the updated data (this is called auto-versioning),
• all the versions of a given document are held in the same folder (this is called version-independent filing, the opposite is called version-specific filing),
• only a single version of a document (the latest version or latest major version) may be filed in a folder, the other versions being "hidden" (not filed); when new versions or new major versions are created they automatically replace the previous one filed in the folder (this is another aspect of version-independent filing).

Given this wide variation of capabilities, having a generic client that understands all the versioning models will certainly be a challenge, but this is the cost of having interoperability with many systems that have different ideas of what versioning should look like.

Security through ACLs

Being able to access documents is the basis of content management, but in existing systems this access is often restricted by various permissions that depend on the user doing the action. The permission systems implemented by content repositories are extremely varied (even more than for versioning), and even though CMIS cannot hope to model them in an interoperable manner it's been recognized that some minimal operations can be agreed upon.

In order to work with permissions, a basic (and optional) set of permission management operations has been defined, based on access control lists (ACLs). The ACL on a document is a list of basic assignment of permissions to users, defining what they can do on this document.

CMIS defines three basic permissions: Read, Write, and All. It's up to each repository to define exactly the semantics of these permissions, but they are common enough that a client should be able to work with them easily even if the details are unknown to it: a client can easily tell a user if it will have the right to modify a document or not.

If a client really needs it, however, the CMIS repository exposes exactly what individual CMIS operations are allowed for each of these permissions. A repository can also define additional non-standard permissions, and using the same mechanism tell a client what operations will be allowed for each. In this manner, a client can discover in advance the restrictions placed on a document.

Optionally, a repository may allow a client to not only check but also change the ACL on a document, so that for instance other users are given rights to modify it, or instead disallowed from even seeing it.

ACLs are often more complex than just a list of permissions given to users on a document, for example many systems have inheritance of ACLs, which means that an ACL applied to a folder has an effect on the documents filed in that folder, and also on other documents further down the tree. Other systems have more complex rules. A CMIS repository can tell a client which of these three models (object-only, with inheritance, or completely repository-specific) it uses. When retrieving the ACL effective on a document, a repository can also tell a client if the ACL has really been set directly on that document, or if has somehow been derived from inherited ACLs or through more complex policies.

Change Log

It's important for external search services, caching systems or synchronization engines to be able to know what has happened in a repository since their "last visit". To that end, CMIS has an (optional) change log service that can be queried to discover the past operations that have been done in the repository after a specified date.

The change log service returns a list of basic operations that have happened in the repository: object creation, modification or deletion, as well as security changes on an object. For modification operations, the repository may also include the new values of properties set on that object.

The change log can be queried by starting from a given point in time materialized by an opaque "change log token", which a client should ask to the repository whenever it checkpoints its state. The repository will later be capable of returning all the changes made since that time.

If the repository cannot record all its history since it was created, the change log may be "incomplete"; in that case it may not be possible to get a change log starting from very old change log tokens. However when a repository returns changes from a supported change log token, all the changes up to the current moment must be returned: no intermediate changes can be lost.

Conclusion

I hope that this overview of its advanced features has convinced you that CMIS is a worthwhile standard, that many powerful things can be done with it, and that many vendors will soon be using it for interoperability. Nuxeo is committed to CMIS, and we'll be releasing a new version of our CMIS connector, supporting the latest 1.0cd04 draft, in a few days.

A final approval of CMIS 1.0 is expected in early-to-mid 2010. In the meantime, the Public Review of CMIS is still under way, please read the spec, implement it, and give feedback!

On the second day of the CMIS face-to-face meeting we again spent some quality time reading the spec nearly line by line, making sure everything is coherent, and discussing a few important points that people felt were important for their use cases.

Below I’ll outline some important changes made to the spec on the first and second day of this meeting. There’s more of course, you may want to follow everything in the CMIS JIRA.

The XML and XHTML property types are gone. No vendor was in support of them, and it was actually quite hard to standardize on exactly what kind of XML would be stored in such a property (well-formed? fragment? etc.). We kept the HTML property type, as many repositories still want to distinguish between “basic text” and “rich text”, especially for presentation purposes. If a repository has XML or XHTML properties, it can easily expose them as Strings.

The ability to use paths to get to folders was extended to documents as well (getFolderByPath turns into getObjectByPath). For folders (were paths are well-defined), paths are retrieved through an explicit property “cmis:path”, but for documents (which may be multi-filed) we have to be more careful. Whenever a document is retrieved in the context of a folder (getChildren, getDescendants, getObjectParents), its last path segment inside that folder will be available, so that clients can determine a full path for the document — but this segment is not a real property of the document, as it may change depending on context. Finally, the “cmis:name” property will be only a hint for the repository to choose a path segment for new objects, but the only way to be sure of an object’s path is through folder’s cmis:path and the aforementioned document path segment.

ACLs have been available since 0.62, but the exact set of basic permissions that they can expose is hard to pin down. We had cmis:read, cmis:write, cmis:delete and cmis:all, however some vendors have a hard time mapping their native permissions (or pseudo-roles) to such a basic model, and especially to cmis:delete which in itself is ambiguous considering that in a given repository deleting an object may require some permission on the parent and some other permission on the child. To further simplify the model, it’s been decided that cmis:delete would go. But fear not, the ACL model is such that each vendor has the possibility of exposing its native permissions, and exposing which of them are required for each of the CMIS operations, so clients will still be able to make good use of ACLs even if not everything about them is standardized.

With ACLs come principals, and some special principals are sufficiently common that it’s worthwhile for a client to know their ids. Therefore we added a way for a repository to tell a client what’s the principal id for “anonymous”, what’s the one for “everybody”, and we added a way to specify “me” when setting ACLs.

The need for Policies has been discussed as well, as there are no actual uses of them in the spec; they’re an abstract placeholder for vendor extensions. Should they go? We now have ACLs after all… But there are already vendors making use of them to expose features of their repositories, so keeping them is good for them, and costs little to others (they’re optional after all).

We now have a way to do copies! For the longest of time, this wasn’t the case. There was strong opposition to adding a copy method, as copy semantics is very varied among repositories (do you copy document relations? acls? versions? renditions? streams? folder children? what about multi-filing? etc.). Nevertheless myself and others persistently asked for a way to do copies. The deciding argument this time was that even though in most cases the clients can do the copy themselves, by just creating a new object with the same properties as the one to copy, there is a problem with content streams as they may be multi-gigabyte objects — at a minimum we need a way to copy content streams. After lots of discussions, we decided to introduce a createDocumentFromSource method, which works just like a normal creation except that a source document is also provided. The repository will then use whatever it feels is best from this source document to fill in the created document. Note that we don’t specify a way to do folder copies, as these very too much between implementations.

In AtomPub, if you want to create a document with a content stream, you have several standard ways available. However the only way to do creation in just one call is to embed the content stream in the message, and AtomPub has strong constraints on how you can do that: for XML- or text-related content types, AtomPub mandates that the stream be inlined in clear text (presumably for the benefit of AtomPub readers). But this is problematic as soon as you want to transfer content that is slightly invalid (but nevertheless stored in your repository!), or whose text content encoding is unknown, or is XML where you want to keep exact formatting, comments, prefixes, namespaces and all. Therefore, we added an extension to AtomPub (cmisra:content) that allows base64 transfer of content in all cases.

URI templates had been added to the AtomPub bindings in order to have a non-REST but very fast way for a client to access a document by ID, by path, or to make a query without a POST. URI templates, however, are still a draft, and it’s problematic to include them in a standard. Furthermore the URI templates draft specifies many different ways along which variable replacement can be done, including tests, defaults, list delimiters, escaping, etc. We thus decided that a simplified subset would be used: just simple {variable} replacement, with percent-escaping. This solves most of the problems, and is still better than nothing.

Today is the third and last day of the meeting, mostly filled with interoperability tests and still more discussions about the spec. Stay tuned for more!

Here are a few highlights of what transpired during this first day.

First, CMIS is really taking hold inside the big companies in this TC. Most of them plan to make available, privately to other TC members, some test versions of the CMIS servers they are working on, to ensure interoperability as early as possible. Of course these face-to-face meetings are also designed as “plugfests”, where we set up test servers and let other’s clients connect to them, but it’s important to have it continue beyond these three days of meetings. It’s unfortunate that these servers can’t be public, but it’s a fact of life inside big companies that you can’t publicly speak about or show what you’re working on.

Of course in the open source world we have much more latitude, and Nuxeo will be putting up soon a page with instructions for downloading and using Apache Chemistry and the Nuxeo CMIS bindings, as well as a public server that people can use for testing. And with all the code available!

Another thing that became clear today is that everybody is pretty happy with the spec as it is, and that we’re nearly ready to start the OASIS review process that will first make it go through formal public review, and then open the OASIS vote for CMIS to become a standard. This process takes time (a minimum of four month), so we should start it as early as possible. But this means that, baring problems, CMIS should be a 1.0 standard by the end of the year, which is great news!

Much of the afternoon of this first day was taken up by a paragraph-by-paragraph review of the spec, where we criticized, clarified, reworded, or otherwise discussed every aspect of the spec. This process is long but invaluable, and we all agree that it makes the spec better. It will continue tomorrow and the day after, both for the first part that describes the domain model, and for the AtomPub and SOAP bindings.

Stay tuned for more news…

(The second part of this series describes the second day of the meeting.)