THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
No Format |
---|
- 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
- Support atom:info - We aren't supporting this right now which means we don't get any feeds' description.
|