/ Thomas Broyer <[EMAIL PROTECTED]> was heard to say:
| Norman Walsh wrote:
|> I'm not sure the -06 draft tells a consistent story about
|> extensibility.
| [...]
|> Should they also be allowed *between* atom:entry elements in a feed?
|
| As the spec uses "interleave" content models, I think they a
I've updated my Atom to RDF/XML XSLT transform to implement draft-06.
I think that it implements everything, including:
* xml:lang and xml:base resolution
* Structured and Simple Extension constructs
* Resolving of defaulted atom:author elements.
There is an RDFS schema of the model up the
Norman Walsh wrote:
I'm not sure the -06 draft tells a consistent story about
extensibility.
[...]
Should they also be allowed *between* atom:entry elements in a feed?
As the spec uses "interleave" content models, I think they are/will...
though I wonder why interlaced content models are used inst
I'm not sure the -06 draft tells a consistent story about
extensibility.
| 6.2 Extensions To the Atom Vocabulary
|
|Future versions of this specification may add new elements and
|attributes to the Atom markup vocabulary. Software written to
|conform to this version of the specifica
Norman Walsh wrote:
I'm not sure the -06 draft tells a consistent story about
extensibility.
It doesn't.
http://www.imc.org/atom-syntax/mail-archive/msg13845.html
That last paragraph suggests that foreign markup *not* from the Atom
vocabulary may not appear at any location, that it must only appear
Oops. One more.
| 6.2 Extensions To the Atom Vocabulary
|
|Future versions of this specification may add new elements and
|attributes to the Atom markup vocabulary. Software written to
|conform to this version of the specification will not be able to
|process such markup correct
| 1.3 Notational Conventions
|
|This specification describes conformance in terms of two kinds of
|artefacts; Atom Feed Documents and Atom Entry documents.
s/artefacts/artifacts/
I gather artefact is the common British variant, so feel free to
ignore this suggestion if you prefer the 'e
/ Graham <[EMAIL PROTECTED]> was heard to say:
| Also, the regex begins:
|
| [0-9]{8}T
|
| Which unless I'm mistaken requires the date section to be exactly 8
| digits with no punctuation. Yet RFC3339 defines the date section as
| having hyphens:
Agreed. That should be [0-9]{4}-[0-9]{2}-[0-9]{2}
