THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
I finally had a chance to review 2/3rds of the Atom spec last night and wanted to publish my notes.
- We do NOT support /atom:entry > An Atom Feed Document is a representation of an Atom feed, including metadata > about the feed, and some or all of the entries associated with it. Its document > element is atom:feed. > An Atom Entry Document represents exactly one Atom Entry, outside of the context > of an Atom Feed. Its document element is atom:entry. - Did the namespace change? namespace atom = "http://purl.org/atom/ns#draft-ietf-atompub-format-05" - We need to comply with xml:base more: Any element in an Atom Document MAY have an xml:base attribute. XML Base [W3C.REC-xmlbase-20010627] processing MUST be applied to any relative reference [RFC3986] present in an Atom Document. This includes such elements and attributes as specified by Atom itself, as well as those specified by extensions to Atom. - I guess ANY item can have an onLocale() change Any element in an Atom Document MAY have an xml:lang attribute, whose content indicates the natural language of the element's content. Requirements regarding the content and interpretation of xml:lang are specified in XML 1.0 [W3C.REC-xml-20040204] Section 2.12. - New changes with the TYPE attribute: Text constructs MAY have a "type" attribute. When present, the value MUST be one of "TEXT", "HTML" or "XHTML". If the "type" attribute is not provided, software MUST behave as though it were present with a value of "TEXT". Note that MIME media types [RFC2045] are not acceptable values for the "type" attribute. - When the type is HTML we MUST escape it: If the value of "type" is "HTML", the content of the Text construct MUST NOT contain child elements, and SHOULD be suitable for handling by software that knows HTML. The HTML markup must be escaped; for example, "<br>" as "<br>". The HTML markup SHOULD be such that it - XHTML support and tests: If the value of "type" is "XHTML", the content of the Text construct MAY contain child elements. The content SHOULD be XHTML text and markup that could validly appear directly within an xhtml:div element. Receiving software which displays the content MAY use the markup to aid in displaying it. Escaped markup is interpreted as a text representation of markup, and MUST NOT be interpreted as markup itself. - We need BETTER atom:person and general author support within the FeedParser: A Person construct is an element that describes a person, corporation, or similar entity. Person constructs MAY be extended by namespace-qualified element children. This specification assigns no significance to the order of appearance of the child elements in a Person construct. atomPersonConstruct = atomCommonAttributes, (element atom:name { text } & element atom:uri { atomUri }? & element atom:email { atomEmailAddress }?) FeedParserListener onAuthor( String name, String resource, String email ) - 3.4 Service Constructs A Service construct is an empty element that conveys the URI of an Atom Publishing Protocol [Atom-protocol] service associated with an entry or feed. atomServiceConstruct = atomCommonAttributes, attribute href { atomUri } - We currently have no atom:generator support or equivalent API. Is there an equivalent spec for RSS 2.0? Yes... and its called generator and is under the channel element. - atom:head WITHIN atom:entry? OK... now THIS is confusing. Don't implement this until Atom 0.5 is released. 4.2.1 Usage of "atom:head" within "atom:entry" In this case, the atom:head element acts as a container for metadata about the feed within which the entry was created. If an atom:entry is copied into one feed from another feed, then the atom:head element of the source feed SHOULD be inserted into the atom:entry unless the entry, as copied, already contains an atom:head element. If the atom:entry already contains an atom:head, then that atom:head SHOULD be copied without modification. - atom:author within atom:entry