Atom

The Atom User Case

Allow expression of the constraints imposed on Atom streams by the Atom spec.

Source: Alex Milowski

Other use cases: Co-constraint Use Cases

Description

I'll assome the 'atom' prefix mapps to 'http://www.w3.org/2005/Atom' in this document.

1. Atom 'text' constructs have one of several forms:

• Text:

   <atom:title type="text">
      ...text here...
   </atom:title>

• HTML:

   <atom:title type="html">
      ...escaped html here...
   </atom:title>

• XHTML:

    <atom:title type="xhtml" xmlns:xhtml="http://www.w3.org/1999/xhtml">
     <xhtml:div>
         ...xhtml here...
     </xhtml:div>
   </atom:title>

  In certain cases, you can also have a mime type:

   <atom:content type='text/xml'>
     <random-xml-here/>
   </atom:content>

  Non-text image mime type:

   <atom:content type='image/jpeg'>...base64 here...</atom:content>

  Essentially, the 'type' attribute controls the content type of the element.  In the Atom RFC, this construct is re-used all over the place and so one or two good types would cover all the text-typed elements.

  The validation rules are:

• if 'type' is 'text', 'html', the content should be xs:string
• if 'type' is 'xhtml', the content must contain an XHTML 'div' element.
• if the 'type' is 'text/xml', the content must contain a single root element. It might be nice to be able to validate that element. There may be additional mime types that should be parsed as XML. I expect a user of the schema would have to enumerate these.
• if the 'type' attribute is 'text/*' and not 'text/xml', the content should be xs:string
• if the 'image/*' or 'application/*', the content should be xs:base64

2. The person construct is the simplest example of an extensible element in Atom. The definition is:

  AtomPersonConstruct =
     atomCommonAttributes,
     (element atom:name { text }
      & element atom:uri { atomUri }?
      & element atom:email { atomEmailAddress }?
      & extensionElement*)

  but another way to describe this is with some constraints:

  The element has 'element-only' content with a any wildcard which must match the following constraints:

• any attribute (as the common attributes are just xml:base and xml:lang)
• only one optional [atom:]name element
• only one optional [atom:]uri element
• only one optional [atom:]email element

3. Most elements map nicely to regular simple types or complex typed elements. For example, a date construct is:

  atomDateConstruct =
     atomCommonAttributes,
     xsd:dateTime

  This is just an element with xs:dateTime content that allows any attributes.

4. An Atom document starts with a 'feed' element whose definition is:

  atomFeed =
     element atom:feed {
        atomCommonAttributes,
        (atomAuthor*
         & atomCategory*
         & atomContributor*
         & atomGenerator?
         & atomIcon?
         & atomId
         & atomLink*
         & atomLogo?
         & atomRights?
         & atomSubtitle?
         & atomTitle
         & atomUpdated
         & extensionElement*),
        atomEntry*
     }

  I believe this can be re-formulated with constraints:

• An [atom:]feed element can contain any element except that [atom:entry] elements must all be the last group of elements and that it may have any element.

    That is, I want:

      (any-element-not-any-atom-entry*,[atom:]entry*)

    This could be specified as a constraint:

      - the content model is (any-element*)
      - the constraint is that [atom:]entry are siblings and
        occur last

• The [atom:]feed element must meet the following constraints:
  • it may contain zero or more [atom:]category elements who must be siblings.
  • it may contain zero or more [atom:]contributor elements who must be siblings.
  • it may contain an optional [atom:]generator element
  • it may contain an optional [atom:]icon element
  • it must contain an [atom:]id element
  • it may contain zero or more [atom:]link elements who must be siblings.
  • it may contain an optional [atom:]logo element
  • it may contain an optional [atom:]rights element
  • it may contain an optional [atom:]subtitle element
  • it must contain an [atom:]title element
  • it must contain an [atom:]update element

5. The [atom:]entry element is defined as:

   atomEntry =
      element atom:entry {
        atomCommonAttributes,
        (atomAuthor*
         & atomCategory*
         & atomContent?
         & atomContributor*
         & atomId
         & atomLink*
         & atomPublished?
         & atomRights?
         & atomSource?
         & atomSummary?
         & atomTitle
         & atomUpdated
         & extensionElement*)
     }

  I believe this can be re-formulated with constraints:

• An [atom:]entry element is element-only with allowing any element and any attirbute.
• The [atom:]entry element must meet the following constraints:
  • it may contain zero or more [atom:]author elements who must be siblings.
  • it may contain zero or more [atom:]category elements who must be siblings.
  • it may contain zero or more [atom:]contributor elements who must be siblings.
  • it must contain an [atom:]id element
  • it may contain zero or more [atom:]link elements who must be siblings.
  • it may contain an optional [atom:]published element
  • it may contain an optional [atom:]rights element
  • it may contain an optional [atom:]source element
  • it may contain an optional [atom:]summary element
  • it must contain an [atom:]title element
  • it must contain an [atom:]update element

6. An optional feature here would be to disallow undefined elements in the Atom namespace. That should be at option to the schema author depending on whether they want to enforce that or not.

Analysis

(Add your analysis here; see your name in pixels!)

Alex Milowski

See the analysis at atom example, with possible solution based on special-casing the type attribute.