Re: Atom extensibility, RDF, and GRDDL

2005-01-07 Thread Robert Sayre
of the Atom model? The arbitrary extension that RDF allows is not what we need--there's a reason almost no one syndicates complex objects in dc:subject statements. Robert Sayre [0] http://www.imc.org/atom-syntax/mail-archive/msg11935.html [1] http://www.imc.org/atom-syntax/mail-archive/msg11936

Re: Atom Link element

2005-01-09 Thread Robert Sayre
Henry Story wrote: On 7 Jan 2005, at 21:56, Robert Sayre wrote: Henry Story wrote: The question is exactly how should the interesting discovery that an Atom document is an RDF document [Ø] be used to fulfill the charter requirements on extensibility? Have you figured out a way to deal

format-04 HTML, diffs

2005-01-11 Thread Robert Sayre
could work against it. Robert Sayre

Re: Questions about -04

2005-01-12 Thread Robert Sayre
want to prohibit them? I think we should drop that sentence. Robert Sayre

Re: PacePropertyDesign

2005-01-12 Thread Robert Sayre
I never finished this Pace, and it can be considered withdrawn. Robert Sayre Antone Roundy wrote: http://www.intertwingly.net/wiki/pie/PacePropertyDesign * Simple The content of the element MUST be CDATA, and have no attributes. Perhaps character data instead of CDATA would be better

Re: Posted PaceExtensionConstruct

2005-01-12 Thread Robert Sayre
of putting in there is FOAF, but that works just as well as a child of entry. I don't think 9.1.1 or 9.1.2 are necessary. We should also mention what it means to add markup elsewhere. I think we should allow it, make it mustIgnore, and make its meaning undefined. Robert Sayre

Re: Posted PaceExtensionConstruct

2005-01-12 Thread Robert Sayre
contributors. Right, what's the use case? FOAF doesn't need to be contained by atom:person. Again, I'm not up for banning it, just making it undefined. Robert Sayre

Re: Questions about -04

2005-01-12 Thread Robert Sayre
points at a web page that vaguely relates to the origin of the feed. That seems ok to me, in the absence of a better alternate. Remember folks, this is about feed-level links, not entries. Links in entries are allowed to be omitted if there's atom:content (PaceContentOrLink, format-04). Robert

Re: PaceMustUnderstandElement

2005-01-13 Thread Robert Sayre
directly. For example, SafariRSS parses feeds with an XQuery script. They also store entries forever, but maybe they don't version feed properties. What happens to their implementation if a feed intermittently contains these mU declarations? I'm confused by it. Robert Sayre [0] http

Re: PaceExtensibilityAndVersioning

2005-01-14 Thread Robert Sayre
Tim Bray wrote: -0 I could live with this, but I think PaceMustUnderstandElement buys 80% of the benefit with 20% of the cost/apparatus. -Tim -1. I suspect everyone else giving PaceMustUnderstand -1s will feel the same. Robert Sayre

Re: PaceMinimalEntryVersioning

2005-01-14 Thread Robert Sayre
Tim Bray wrote: -1 I think this issue has been discussed to death and the current consensus around atom:id and atom:updated will meet users' needs simply and elegantly. Trying to achieve consensus on a generalized abstract model of versioning is doomed to failure. -Tim -1 as well. Robert

Re: Feed, know thyself?

2005-01-14 Thread Robert Sayre
will deal with it eventually (Safari 2.0 does...) and/or we'll get a playlist type thing. That's the only way it will work reliably. Robert Sayre

Re: Posted PaceSimpleLanguageTagging

2005-01-17 Thread Robert Sayre
an xml:lang declaration on atom:updated? Robert Sayre

Re: Posted PaceSimpleLanguageTagging

2005-01-17 Thread Robert Sayre
of the predefined locations, it could be discarded, because it's outside the Atom model. Robert Sayre

Re: PaceSyntaxGuidelines status

2005-01-24 Thread Robert Sayre
reading it, imitate the examples, and end up with similar syntax anyway. People who take the time to read the spec are even less likely to do something ugly. That mostly leaves elements from existing vocabularies. Robert Sayre

Re: The probably-last gang of issues

2005-01-24 Thread Robert Sayre
suspect Graham will prefer it. We can pick up the pace to incorporate wording and nitpick changes. Robert Sayre

Re: PaceSyntaxGuidelines status

2005-01-25 Thread Robert Sayre
with the goal, but it's not appropriate to include in the spec. It's babysitting. If the mythical Implementor's Guide were to materialize, it might make a good home for this text. Robert Sayre

Re: PaceMustBeWellFormed status

2005-01-25 Thread Robert Sayre
Walter Underwood wrote: --On Tuesday, January 25, 2005 03:39:13 PM -0500 Robert Sayre [EMAIL PROTECTED] wrote: I'm very -1 on this, since it makes the definition of the Atom format an HTTP message, rather than an XML document. On top of that, most of the Pace is babysitting. To the Guide

Re: Issues with draft-ietf-atompub-format-04

2005-01-25 Thread Robert Sayre
a large SVG graphic in my feed which has the MIME type image/svg+xml. Should I include it into the feed? You have lots of options that don't require fallback content. We rejected xhtml:object a long time ago. Robert Sayre

Re: PaceMustBeWellFormed status

2005-01-25 Thread Robert Sayre
wrapped up in HTTP, pedantic, and incorrect in numerous ways. Robert Sayre

Re: Issues with draft-ietf-atompub-format-04

2005-01-25 Thread Robert Sayre
in front of you. Bring this issue up again after the next draft if you still think it's worthwhile to embark on a campaign to rename an attribute. Robert Sayre

Re: PaceMustBeWellFormed status

2005-01-26 Thread Robert Sayre
-formed XML. So, Atom documents are well-formed XML identified with the Atom media type. The specification doesn't talk about other media types or ill-formed XML documents. Is there something more we can add to the specification? I don't think PaceMustBeWellFormed is it. Robert Sayre

Re: Difference of TEXT and XHTML?

2005-01-27 Thread Robert Sayre
between ASCII and UTF-8). -1 on the pace. -1 as well. Allowing people to assert they are using a subset of what's available is not a design error. Graham (PS Are line breaks in Text mode honored?) The current text says whitespace collapsing is allowed. Robert Sayre

Re: Multiple content allowed?

2005-01-27 Thread Robert Sayre
. Robert Sayre

Re: Issues with draft-ietf-atompub-format-04

2005-01-27 Thread Robert Sayre
Henri Sivonen wrote: On Jan 27, 2005, at 22:39, Robert Sayre wrote: Anne van Kesteren wrote: So I can not include MathML in the TITLE of my weblog? I do not see why this restriction is necessary. Nope. Can any aggregator display it? I expect Gecko-based aggregators to support MathML eventually

Re: PaceFormatSecurity

2005-01-28 Thread Robert Sayre
with it is not on, especially when they're this drastic. Agree w/ Graham. We don't know what kind of relationship the publisher and consumer have. I would strike all the details on HTML, leave the first paragraph, and refer to the security sections of RFC 2854 and HTML 4.01. Robert Sayre

Re: PaceFormatSecurity

2005-01-28 Thread Robert Sayre
to find such a reference myself. Maybe someone else has better google-fu than me. I guess the question is whether we can and should outline HTML security issues. I don't think we can or should. Robert Sayre

Re: PaceIRI status: RFC 3987 and STD 66, RFC 3986, published

2005-01-28 Thread Robert Sayre
all, the catch phrase is not Cool IRIs Don't Change. What can we do minimize confusion? Robert Sayre

PaceFeedRecursive is filled in

2005-01-29 Thread Robert Sayre
(mI), so the authors of those Paces should take a look. Robert Sayre

Re: Proof-of-concept RDF mapping for Atom

2005-01-29 Thread Robert Sayre
should be normatively defined w/ XSLT. It meets the cross-platform requirements of the IETF and is unambiguous. Of course, it had better be really good! If someone wants to optimize with a SAX version, they still can. Robert Sayre

Re: Comments on format-05

2005-01-30 Thread Robert Sayre
that this was raised again. We went over and over on the matter, and no one ever used them anyway. Robert Sayre

Re: Comments on format-05

2005-01-30 Thread Robert Sayre
this heavily already. One example is FeedBurner feeds that incorporate Atom feeds. They know they can show the info element as an explanation. Without a standard element, they will have to write 90% similar code for every blogging vendor. It should be standardized. Robert Sayre

Re: Comments on format-05

2005-01-30 Thread Robert Sayre
on the matter, and no one ever used them anyway. +1. I think it is important to include multiple translation in a single feed. I'm sorry, this was decided months ago. Why don't you go back and read why it happened. If we have multilple content elements, I propose that we rename it to element. Robert

Re: Obs on format-05

2005-01-30 Thread Robert Sayre
available where one consumer will only ever use half of the content is bad practice. Use two resources. If we were looking for a way to make the bandwidth problem much, much worse, this would be one way. Robert Sayre

Re: Comments on format-05

2005-01-30 Thread Robert Sayre
Sam Ruby wrote: Robert Sayre wrote: * 4.21 The atom:info Element -- If it's not considered meaningful for processors, why does there need to be a standard element for it? At the very least, some sort of information about its semantics should be documented. My preference would be to drop

Re: Comments on format-05

2005-01-30 Thread Robert Sayre
useful as shorthand for less technical people. So, no change to the spec is necessary. I understand you are looking for the spec to guide the validators behavior, but I don't think it should. Robert Sayre

Re: PaceFeedRecursive is filled in

2005-01-30 Thread Robert Sayre
Sam Ruby wrote: Robert, can you take a stab at updating section 1.2 for this Pace? Yes, but the Pace is complete without it. I'll also note that this example is not valid. It does not contain either a summary or content element. Hmm. How do I do a linkblog with this restriction? Robert Sayre

Re: URI canonicalization

2005-01-30 Thread Robert Sayre
/thing You cannot count on a positive or negative, and you are sloppy. Robert Sayre

Re: URI canonicalization

2005-01-30 Thread Robert Sayre
Julian Reschke wrote: Robert Sayre wrote: Um, the spec doesn't say you can. If the comparision is done with URI.equals(), it will be positive. If it is done with String.equals(), it will be negative. That text is a refelection of reality. http://atompub.org/2005/01/27/draft-ietf-atompub-format

Re: Comments on format-05

2005-01-30 Thread Robert Sayre
? If the validator does not look to the spec for guidance, where should it look? If somebody can answer my questions, I would appreciate it.. I think the spec should cover Atom documents identified with the Atom media type. Other types are undefined. Robert Sayre

Re: PaceFeedRecursive is filled in

2005-01-30 Thread Robert Sayre
Sam Ruby wrote: Robert Sayre wrote: Sam Ruby wrote: Robert, can you take a stab at updating section 1.2 for this Pace? Yes, but the Pace is complete without it. It would be much easier to discuss the pace with an example. I suspect that once people see some examples, objections will surface

Re: Comments on format-05

2005-01-30 Thread Robert Sayre
Sam Ruby wrote: Robert Sayre wrote: If I am conflating validity with media types, then so is the XML specification. I don't understand that, could you explain? See the XML specification section F.2 [1]. It is quite possible for an XML document to be valid if served with media type

Re: Comments on draft 05, was: I-D ACTION:draft-ietf-atompub-format-05.txt

2005-01-30 Thread Robert Sayre
://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.references Here's a procedural question: if we have normative references to the protocol and the feed discovery documents, the spec won't get published until those are done, too. Is everybody aware of that? Yep. Robert Sayre

Re: URI canonicalization

2005-01-30 Thread Robert Sayre
Eric Scheid wrote: On 31/1/05 6:17 AM, Robert Sayre [EMAIL PROTECTED] wrote: Instances of Identity constructs can be compared to determine whether an entry or feed is the same as one seen before. Processors MUST compare Identity constructs on a character-by-character basis in a case-sensitive

Re: URI canonicalization

2005-01-30 Thread Robert Sayre
Eric Scheid wrote: On 31/1/05 10:16 AM, Robert Sayre [EMAIL PROTECTED] wrote: I agree with you in principle, but I find the current text unrealistic. It's just fodder for stupid arguments. what? and Atom Processors MAY perform additional scheme-specific comparisions won't lead to stupid

Re: PaceFeedRecursive is filled in

2005-01-30 Thread Robert Sayre
Sam Ruby wrote: Robert Sayre wrote: Sam Ruby wrote: Robert, can you take a stab at updating section 1.2 for this Pace? Yes, but the Pace is complete without it. It would be much easier to discuss the pace with an example. I gather that a format-05 compatible feed, thus: I suspect that once

Re: URI canonicalization

2005-01-30 Thread Robert Sayre
Graham wrote: On 31 Jan 2005, at 12:16 am, Robert Sayre wrote: Graham wrote: Yeah, that's a horrible loose end to leave hanging. No, it isn't. URI comparison is not our problem, and what our spec says about it doesn't matter a bit. Yes it is times one million. Ha ha I win et cetera Defining

Re: URI canonicalization

2005-01-30 Thread Robert Sayre
Graham wrote: On 31 Jan 2005, at 12:43 am, Robert Sayre wrote: How about Make sure your id is unique from a character-by-character perspective, but also unique in the face of scheme-specific comparisons. That is, don't lean on scheme-specific comparisons to match URIs, but they don't have

Re: Dereferencing Identity Constructs

2005-01-30 Thread Robert Sayre
dereferenced. Secondly, I fail to see how dereferencing a URI would cause interop problems. Robert Sayre

Re: atom:info [was Re: Comments on format-05]

2005-01-30 Thread Robert Sayre
RFCs that I'd rather not mess with. Robert Sayre

Re: atom:host [was: Comments on format-05]

2005-01-30 Thread Robert Sayre
' has morphed into, than I'd rather see it dropped. Thanks for bringing up this problem. atom:nameAnonymous (from IP: aaa.bbb.ccc.)/atom:name Yay! Let's drop atom:host. Robert Sayre

Re: Comments on draft 05, was: I-D ACTION:draft-ietf-atompub-form at-05.txt

2005-01-31 Thread Robert Sayre
Henri Sivonen wrote: On Jan 31, 2005, at 00:53, Robert Sayre wrote: I think this should come with the following URL: http://www.oasis-open.org/committees/relax-ng/spec-20011203.html I don't want to refer to OASIS's URLs. Why not? Will ISO-Relax NG be available on the Web free of charge? Specs

Re: Comments on draft 05, was: I-D ACTION:draft-ietf-atompub-format-05.txt

2005-01-31 Thread Robert Sayre
Julian Reschke wrote: Thanks for the feedback, Robert... Robert Sayre wrote: - rel attribute is missing The rel attribute is optional and the relation is considered to be alternate in that case. http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rel_attribute http://atompub.org

Re: atom:info [was Re: Comments on format-05]

2005-01-31 Thread Robert Sayre
Bjoern Hoehrmann wrote: * Robert Sayre wrote: If I tell NetNewsWire to GET something in the subscribe dialog, my dispatching instructions are clear. Everything is a feed. Making up rules for application/xml, text/xml, and application/octet-stream will require superceding some RFCs that I'd

Re: Comments on draft 05, was: I-D ACTION:draft-ietf-atompub-format-05.txt

2005-01-31 Thread Robert Sayre
Julian Reschke wrote: Robert Sayre wrote: 'atom:head elements MUST contain at least one atom:link element with a rel attribute value of alternate.' Point taken. How about 'atom:head elements MUST contain at least one atom:link element with a relation of alternate.' Can't we just get rid

Re: atom:info [was Re: Comments on format-05]

2005-01-31 Thread Robert Sayre
. Robert Sayre

IRIs (was: Re: Work Queue Rotation #16)

2005-01-31 Thread Robert Sayre
, snarky, slang-ridden proceedings in English to declare consensus against them. So, I concur with the chairs, even though the cost concerns me and IRIs are certain to cause problems in the short-term. Robert Sayre

Re: PaceAggregationDocument posted

2005-01-31 Thread Robert Sayre
to atom:entry that indicates whether it refers to an instance of entry or another feed 4.) current draft (head in entry and all that) 5.) PaceAggregationDocument Robert Sayre

Re: PaceAggregationDocument posted

2005-01-31 Thread Robert Sayre
and Perl suck equally. Ruby is surprisingly elegant when you get to thinking about it. OS X and Windows suck equally. Linux is surprisingly elegant when you get to thinking about it. Robert Sayre

Re: URI canonicalization

2005-01-31 Thread Robert Sayre
Robert Sayre wrote: 4) Add a sentence saying something like Feeds or Entries are identical if their IDs compare identical.. Seems obvious, but isn't stated anywhere. No. Feeds/entries with the same id are different versions or instances of a common ancestor. They are not the same. Martin

Re: Format spec vs Protocol spec

2005-02-01 Thread Robert Sayre
Tim Bray wrote: On Feb 1, 2005, at 1:05 PM, Julian Reschke wrote: Currently, the format spec has a normative reference to the protocol spec (and also defines elements for the service URIs, for instance, atom:introspection). I suggest this can and should be removed. Agree. Robert Sayre

Re: PaceFormatSecurity to be updated?

2005-02-02 Thread Robert Sayre
Joe Gregorio wrote: On Wed, 02 Feb 2005 03:31:18 -0500, Robert Sayre [EMAIL PROTECTED] wrote: 10.1 HTML and XHTML Content Text Constructs and atom:content allow the delivery of HTML and XHTML into a client application. Many elements are considered 'unsafe' in that they open clients to one or more

Re: PaceIconAndImage - icon aspect ratio

2005-02-02 Thread Robert Sayre
why the aspect ratio shouldn't be a MUST? Aren't icons (on computers, anyway) pretty much universally 1:1? LiveJournal images are square. Robert Sayre

PaceRemoveInfoAndHost

2005-02-02 Thread Robert Sayre
. So, let's have the process take over. Robert Sayre

Re: Format spec vs Protocol spec

2005-02-02 Thread Robert Sayre
excede anything we can expect, but some aspects of the model would be extremely valuable to the format and protocol, IMHO. Robert Sayre [0] http://www.25hoursaday.com/weblog/PermaLink.aspx?guid=a257ba40-b9fd-4cba-959a-2bba6ae917f0

Organization Use Cases (was: Re: Format spec vs Protocol spec)

2005-02-02 Thread Robert Sayre
Robert Sayre wrote: The problems facing a server storing blog entries are not much different (whether or not the entries are exposed to APP). Our secretary has listed the following paces as organization paces, meaning they don't change the definition of many core elements other than the ones

Re: Call for final Paces for consideration: deadline imminent

2005-02-02 Thread Robert Sayre
out a critical bug or missing feature in the format, and a significant number of WG participants agree, we should miss our deadline because we no longer have consensus on the *current draft*. Robert Sayre

Re: PaceEntriesElement

2005-02-03 Thread Robert Sayre
be an if/else in the code). Btw, this sounds like it's going to work like RDF/XML striping. Yes, I wrote the initial feed in the RDF validator. Robert Sayre

Re: Exactly one atom:contributor?

2005-02-03 Thread Robert Sayre
that they each contributed to the entry? For that matter, I wonder if the constraint makes sense for author. Kind of, sort of, maybe. That's a typo on my part. The Relax NG is correct. Robert Sayre

Re: atom:content in atom:entry

2005-02-03 Thread Robert Sayre
element would require accessible alternative content, and result in reinvention of the feed structure. Also, no one uses them in Atom 0.3. Take a look at PaceEntriesElement as an alternative. Robert Sayre

Re: On organization and abstraction

2005-02-03 Thread Robert Sayre
friends), if not perhaps widely seen outside of geekland. So I think I'm +1 on PaceAggregationDocument. (And I think if we adopted that we could certainly lose PaceHeadInEntry, right Bob?) I think you should wait for examples. Robert Sayre

Re: Organization Use Cases

2005-02-03 Thread Robert Sayre
Tim Bray wrote: On Feb 2, 2005, at 12:15 PM, Robert Sayre wrote: 1.) A web forum, where one post serves as the root of a collection of other posts. HTML-- http://groups-beta.google.com/group/bloggerDev/ Atom 0.3, root posts only-- http://groups-beta.google.com/group/bloggerDev

Re: On organization and abstraction

2005-02-03 Thread Robert Sayre
define some other document format? OPML will do that just fine. Robert Sayre

Re: On organization and abstraction

2005-02-03 Thread Robert Sayre
The atom:entry element represents an individual entry. I really must find out more about this theology that allows one to divine the precise nature of lists, data, metadata, items, containers, and representations. Robert Sayre

Re: New Pace: PaceAggregationInSeparateSpec

2005-02-03 Thread Robert Sayre
, so there's no reason to leave it in. Robert Sayre

Re: New Pace: PaceAggregationInSeparateSpec

2005-02-04 Thread Robert Sayre
to be atom:head, but it does need to be part of the core. Why? Robert Sayre

issue roundup

2005-02-04 Thread Robert Sayre
: It's faster if you just say C++. Obviously, these aren't going to happen. OK. --- I think that about covers it. Robert Sayre

Re: xsd:dateTime vs. RFC 3339

2005-02-04 Thread Robert Sayre
than RFC 3339. I propose that we change the spec to do so. I agree. I was just writing a protocol implementation in Ruby On Rails (CRUDs very fast, btw). When I got to the part on date formats, I used xsd:dateTime code that was already done, figuring that's what everyone else will do. Robert

Re: PaceIconAndImage

2005-02-04 Thread Robert Sayre
. How does it hurt interop to put an image in an entry? Robert Sayre

Re: Call for final Paces for consideration: deadline imminent

2005-02-04 Thread Robert Sayre
clients to keep separate records of entries with the same id. We should probably be more worried about bad implementions totally missing the point of identifiers, than about good implementations with sophisticated notions of versioning and identifiers. Robert Sayre

Re: Call for final Paces for consideration: deadline imminent

2005-02-04 Thread Robert Sayre
Tim Bray wrote: I'm with Mnot on this one. Just because it uniquely identifies an entry, that doesn't mean you can't have two versions of the same entry in a feed. ... I don't see any reason for ruling them out in a single feed. Robert Sayre wrote: We should probably be more worried about bad

Re: Call for final Paces for consideration: deadline imminent

2005-02-04 Thread Robert Sayre
of the current status of a set of entries, then it only makes sense to include one entry per atom:id. I would argue the second definition makes a lot more sense and accurately reflects real-world usage, where even the RDF formats recommend against repeating rdf:about. Robert Sayre

Re: PaceHeadless

2005-02-04 Thread Robert Sayre
without making an unintentional pun. source-feed is fine. The section on atom:head is totally confusing and bad--it's easier if you just do it the way PubSub does it *right now*. Robert Sayre

Re: Posted PaceEntryOrder (was Entry order)

2005-02-05 Thread Robert Sayre
, including document order. Extensions don't get to make demands on generic Atom processors. Lots feeds will consist of entris with the same date, and lots of aggregators will just show things in the order the SAX parser sent it. Robert Sayre

Re: PaceRepeatIdInDocument posted

2005-02-05 Thread Robert Sayre
the way to do it. Since you're advocating versioning, what are your plans for versioning the state of the feed itself? What if the title changes? It would be better to archive a series of feed documents. Robert Sayre

Re: xsd:dateTime vs. RFC 3339

2005-02-05 Thread Robert Sayre
timestamps where some are lacking the timezone information. I would tend to agree. Can we have that regex go in the Pace itself? That would make the proposal pretty much editorial, since the set of allowed timestamps would be the same (right?). Robert Sayre

Re: xsd:dateTime vs. RFC 3339

2005-02-05 Thread Robert Sayre
Norman Walsh wrote: / Robert Sayre [EMAIL PROTECTED] was heard to say: | I would tend to agree. Can we have that regex go in the Pace itself? The regex is in the pace. I took the liberty of adding it to the proposal section. Robert Sayre

Re: PaceRepeatIdInDocument posted

2005-02-05 Thread Robert Sayre
Bob Wyman wrote: Robert Sayre wrote: Bob Wyman wrote: As long as multiple instances/versions of an entry are permitted to exist in a single atom document while sharing the same atom:id, the current Atom document format provides a useable archive format. This is clearly a non-starter

Re: PaceRepeatIdInDocument posted

2005-02-05 Thread Robert Sayre
for ignoramus apps. BTW, if it weren't for the atrocious design error of banning recursive feeds, we wouldn't even be having this argument. A feed would always mean current status, while a series of them would mean stream. Robert Sayre

Re: PaceRepeatIdInDocument posted

2005-02-05 Thread Robert Sayre
it's a gross hack. So, perhaps atom:archive shouldn't define anything besides atom:entry. Robert Sayre

Re: BAG Question: What is a feed? Sliding-Window or Current-State?

2005-02-06 Thread Robert Sayre
/key true/ keyread/key true/ /dict Also, Thunderbird uses them to compose its message-id. I could go on. Robert Sayre

Re: PaceArchiveDocument posted

2005-02-07 Thread Robert Sayre
after all. Robert Sayre

Re: PaceArchiveDocument posted

2005-02-07 Thread Robert Sayre
-- It must be possible to serialize a complete collection of entries using the Atom Format. Robert Sayre

PaceClarifyDateUpdated

2005-02-07 Thread Robert Sayre
-1. Doesn't make sense or add value to the document. Robert Sayre

Re: PaceEntryOrder

2005-02-07 Thread Robert Sayre
Paul Hoffman wrote: +1. It is a simple clarification that shows the intention without restricting anyone. +1. Agree in full. Robert Sayre

Re: PaceArchiveDocument

2005-02-07 Thread Robert Sayre
Paul Hoffman wrote: -1. Not core. The current text has a simple way of creating archives, and extensions can be used to create more specialized archive formats. -1 to the Pace. Agree in full. Robert Sayre

PaceDatesXSD

2005-02-07 Thread Robert Sayre
+1. Our AD has told us how to write this section, so the Pace just adds the regex, which I'm in favor of. Sam's suggestion at the end could easily be accomodated with a sentence saying As a result, the date values are valid according to [RFC3339], [XML-SCHEMA], and [w3cdtf]. Robert Sayre

PaceSecuritySection

2005-02-07 Thread Robert Sayre
+1. Says all that we need to without getting into HTML too deeply. Robert Sayre

PaceMultipleImages

2005-02-07 Thread Robert Sayre
Some feel that since the atom:image could contain text, multiple instances ought to be allowed for to support multilanguage. These people are wrong. -1 to the Pace. Robert Sayre

Re: PaceIconAndImage

2005-02-07 Thread Robert Sayre
. Alright. Robert Sayre

  1   2   3   4   5   6   >