Re: spec bug: can we fix for draft-11?
Using Sun's 'relames' [1] it is *nearly* possible to validate an instance as is intended by the text! Where (datetime for instance) an element content must not have whitespace, relames picks it up nicely. element name=atom:published s:assert test=normalize-space(.) = .There must be no white space before or after a date time value /s:assert ref name=atomDateConstruct/ /element Unfortunately, as of this release, relames doesn't support Schematron assert statements for attribute values, which is required for uri's. C'est la vie [1]https://msv.dev.java.net/ regards DaveP
Re: spec bug: can we fix for draft-11?
On Thu, 2005-08-04 at 17:45 +0200, Danny Ayers wrote: I don't want to allow whitespace. But this id urn:foo /id is going to happen, is going to cause problems, and working around it does not strike me as being something you can foist entirely onto the spec's end-users. Why is it particularly likely to happen? Because there is nothing to 'see' that looks wrong Danny, and relaxNG has nothing that allows both text (ws) and anyURI to mix. I think that means it needs sneaky words to state it; or tee people off by failing content that 'looks' good. regards DaveP
Re: spec bug: can we fix for draft-11?
On Tue, 2005-08-02 at 15:24 +0100, Bill de hÓra wrote: Sam Ruby wrote: Even if we decide that whitespace is not significant, I do believe that having the feedvalidator issue a warning in such cases is appropriate. +1 What is the IETF version of an errata sheet? Is that the right place to tackle this? I'm with Bill, I'm sure we'll see many instances which have whitespace included, with a simplistic assumption that the element contains an IRI, and nothing more. James makes a good point about whitespace stripping in the other elements. Looking at http://relaxng.org/spec-20011203.html The anyURI symbol has the same meaning as the anyURI datatype of [W3C XML Schema Datatypes]: it indicates a string that, after escaping of disallowed values as described in Section 5.4 of [XLink], is a URI reference as defined in [RFC 2396] (as modified by [RFC 2732]). I can't see how the anyURI fits with element content; all the examples I've seen use it as an attribute value which I think is clearer due to XML 1.0 regards DaveP
Re: spec bug: can we fix for draft-11?
On Tue, 2005-08-02 at 19:11 +0200, Bjoern Hoehrmann wrote: For RFCs see http://www.rfc-editor.org/errata.html. Thanks. Just playing. With schema define name=uriTest element name=test oneOrMore element name=uri attribute name=href data type=anyURI/ /attribute data type=anyURI/ /element /oneOrMore /element /define The example below parses well with James Clarks relax tools and the sun validator. test uri href=http://www.example.com; http://example.com /uri uri href= http://www.example.com http://www.example.com /uri /test regards DaveP
Re: Feed History -02
On Sat, 2005-07-23 at 09:14 -0700, Mark Nottingham wrote: Archives *should not* change. I think any librarian will agree with that. I very much agree that this is the ideal that should be striven for. The underlying problem, I think, is that different feeds have different semantics. I think that's the bottom line Mark. No matter what, people are going to do different things with 'history'. Trying to pin down how it should all work seems to increase the complexity by an order, never a good thing IMHO. How about, you want my history, you make of it what you will. I only guarantee its valid atom? At least that way, processing older feed material can develop based on a sound (and clearly understood) foundation. regards DaveP
Re: Atom 1.0 xml:base/URI funnies
If anyone comes to a definitive conclusion on this, would they post to the list, or a website please. TIA -- Regards, Dave Pawson XSLT + Docbook FAQ http://www.dpawson.co.uk
Re: RNG validators capable of fully using the Atom schema?
On Tue, 2005-07-12 at 10:24 +0200, Bjoern Hoehrmann wrote: * Henri Sivonen wrote: I'm wondering which validator was used for testing the Atom RNG+Schematron schema. Which validators support Compact Syntax with embedded Schematron? I am particularly interested in Java solutions. http://www.topologi.com/products/validator/ is said to support it. I used Norm's relax-ng schema + msv. Seems good to me? http://www.dpawson.co.uk/nodesets/nodesets.xml You tell me if it's bad[==invalid] The spec doesn't ... in language I understand. -- Regards, Dave Pawson XSLT + Docbook FAQ http://www.dpawson.co.uk
Re: RNG validators capable of fully using the Atom schema?
On Tue, 2005-07-12 at 12:16 -0400, Norman Walsh wrote: / Henri Sivonen [EMAIL PROTECTED] was heard to say: | I'm wondering which validator was used for testing the Atom | RNG+Schematron schema. Which validators support Compact Syntax with | embedded Schematron? I am particularly interested in Java solutions. I use Kohsuke's MSV. (msv.dev.java.net) Be seeing you, norm Make sure you pick up the overnight builds. Sun seem lax on keeping the main feed up to date. regards DaveP
Re: Clearing a discuss vote on the Atom format
On Fri, 2005-07-01 at 16:13 -0400, Sam Hartman wrote: Paul, two points. For me to be happy, your specification must mandate that xmldsig be used whenever encryption is used. As a consequence of this and your decision not to support MACs, then in order to encrypt a document, you must sign it. In addition, in order to accept this encrypted document, the recipient must be able to verify your signature. Please confirm with the working group that these requirements are acceptable. In particular this forbids the case where I submit an entry encrypted to some third party who I don't share a PKI with. An aweful lot of 'must's there Sam, for one persons view? I see no reason to using signing, just because I choose to encrypt? Sounds a bit too corner case for my liking. DaveP
Re: FWD: I-D ACTION:draft-nottingham-atompub-feed-history-00.txt
On Wed, 2005-06-29 at 15:03 +0200, Thomas Broyer wrote: Dave Pawson wrote: Any one site could now have n instances, each being a feed, the only variant (apart from entries) being the links to previous feeds. If I'm to say *this* is my feed, I guess I point to the most recent... which will change over time? With the example of 15 entries per, feed1 1..15 feed4 45..60 my 'feed' for my site rolls over from feed1...n as time progresses? I guess the answer is: http://example.com/latest is your feed, e.g. containing the latest 10 entries http://example.com/archive-1 through n are your archive feeds. Which would mean that the instance at /latest keeps changing? I need to keep swapping old ones out, new ones in, i.e. rebuilding each time? I guess that's another reason it feels like a kludge. You can see latest as an Atom alternate for your home page (or latest news page) and archive-1 through archive-n as Atom alternates for your archive pages. I can see the logic of your suggestion. Doesn't seem clean though? snip/ Other issues. regards DaveP
Re: The atom:uri element
On Mon, 2005-06-27 at 12:46 -0700, James Cerra wrote: Please can we have an informative version of the spec, with the semantics explained. Current version, for thicko's|users, like me, is not good. How hard is one little change? I'm not looking for a change. That has been submitted. I'm looking for an informative, not normative, version of the spec, which takes time to explain things instead of being exact, but backed by the experience of this list? Yes, I know the spec is for implementors, but there are authors out here too, who need that information. That I believe is the interop issue. -- Regards, Dave Pawson XSLT + Docbook FAQ http://www.dpawson.co.uk
Re: The atom:uri element
On Mon, 2005-06-27 at 13:42 +0200, Asbjørn Ulsberg wrote: The atom:uri element should be renamed or changed. == Rationale == The atom:uri element says nothing about its semantics or meaning, just about the datatype of its content. == Proposal == Rename the atom:uri element or change its type to a Link Construct. I support the rationale for changing. I'd appreciate even more some semantics for the element? Were you going to add those to the proposal? -- Regards, Dave Pawson XSLT + Docbook FAQ http://www.dpawson.co.uk
Re: The atom:uri element
On Mon, 2005-06-27 at 18:39 +0200, A. Pagaltzis wrote: * Asbjørn Ulsberg [EMAIL PROTECTED] [2005-06-27 13:50]: Rename the atom:uri element or change its type to a Link Construct. The problem with that proposal, even if it wasn’t too late to make any changes, is that, well, it replaces atom:uri with a Link Construct. A Link Construct has more semantics than the atom:uri element is supposed to. Whereas the current construct has no semantics to speak of? The basic idea to rename the element to something more descriptive is, of course, not bad. With little, or no, semantics? But, as mentioned, the spec, modulo bugs, is a done deal at this point. Which, as was pointed out, is not good for interop Please can we have an informative version of the spec, with the semantics explained. Current version, for thicko's|users, like me, is not good. -- Regards, Dave Pawson XSLT + Docbook FAQ http://www.dpawson.co.uk
Re: More on Atom XML signatures and encryption
On Tue, 2005-06-21 at 17:13 -0700, James M Snell wrote: The root of an Atom document (i.e., atom:feed in an Atom Feed Document, atom:entry in an Atom Entry Document) MAY have an Enveloped Signature, as described by XML-Signature and Syntax Processing [W3C.REC-xmldsig-core-20020212]. Given this language, the the spec only explicitly allows digital signing of the Atom Feed and Entry Documents. It does not explicitly allow for digitally signing individual entries within a Feed document. Makes sense to me James. Which bit of 'only explicitly' don't you grok? -- Regards, Dave Pawson XSLT + Docbook FAQ http://www.dpawson.co.uk
feed or entry
I'm not having much luck working out how I can write (daily or there abouts) an entry, without having to duplicate feed metadata. Am I alone in this? Xinsert isn't common yet.. is it? -- Regards, Dave Pawson XSLT + Docbook FAQ http://www.dpawson.co.uk http://www.dpawson.co.uk/blog/
Re: feed or entry
On Thu, 2005-06-16 at 12:09 -0700, James Cerra wrote: Dave Pawson, I'm not having much luck working out how I can write (daily or there abouts) an entry, without having to duplicate feed metadata. I don't follow. Could you give an example showing the duplicated metadata? Process. I write an instance. document element is a:feed. Each successive day (or thereabouts) I write an entry. I'm processing via XSLT. I don't want a single monolith of a file, so I'm writing daily using a document element of a:entry. The end product is an 'empty' a:feed element (i.e. no entry children) and 101 orphan a:entry instances, each with a days content. Possibly because I'm not autogenerating all the metadata (child to a:feed, ancestor to a:entry) daily I'm not in a position to post a single a:feed instance. Is that any clearer? (www.dpawson.co.uk/blog is the outcome) -- Regards, Dave Pawson XSLT + Docbook FAQ http://www.dpawson.co.uk
