Re: PaceLangSpecific
Tuesday, February 8, 2005, 12:44:26 AM, you wrote: PaceLangSpecific +1, but also needed for atom:generator hmmm ... if we have xml:lang on content, we are going to also need @hreflang for content src=... /, because while some types of referenced content can have the language attached, at type=text/plain cannot. text/plain can have a Content-Language header though - is that compatible with xml:lang? -- Dave
Re: PaceStopArguingAboutSlidingWindowsAndCurrentStateEnoughAlready
Henry Story wrote: If you just want to stick to syntax, then please leave the pace as it is. Don't try to impose a model through syntax and then argue that people can't argue about the model that you are surreptitiously trying to introduce. Henry, I have no idea what you are talking about. cheers Bill
Re: PaceXhtmlNamespaceDiv
On Feb 7, 2005, at 23:21, Sam Ruby wrote: 1) Graham (who uses proper XML tools) will have to do more work. Which tools? How much more? One loop more? (FWIW, I do not consider Apple's Core Foundation XML parser a proper XML tool.) 2) Tim (who uses string concatenation) will have to do more work. When I did a string concatenation implementation, using colonified names was not a big deal. 5) For some combinations of clients and servers, entries produced via an HTTP POST will end up with multiple divs. I can anticipate that happening either way. -- Henri Sivonen [EMAIL PROTECTED] http://iki.fi/hsivonen/
Re: PaceXhtmlNamespaceDiv
On Feb 8, 2005, at 07:03, Henri Sivonen wrote: On Feb 8, 2005, at 01:55, Sam Ruby wrote: Can I get one of you three to mock up what Tim's feed should look like? a:feed xmlns:a='http://purl.org/atom/ns#draft-ietf-atompub-format-04' version='draft-ietf-atompub-format-04 : do not deploy' xmlns='http://www.w3.org/1999/xhtml' xml:lang='en-us' ... a:entry ... a:content type='XHTML'I was in the drugstore picking up a prescription and wandered into the computer section, where I found myself impulse-buying a href='http://dvforge.com/themousebt.shtml'The Mouse BT/a from some outfit ... OR (even less impact on string concatenators): feed xmlns='http://purl.org/atom/ns#draft-ietf-atompub-format-04' version='draft-ietf-atompub-format-04 : do not deploy' xml:lang='en-us' ... entry ... a:content type='XHTML' xmlns:a='http://purl.org/atom/ns#draft-ietf-atompub-format-04' xmlns='http://www.w3.org/1999/xhtml'I was in the drugstore picking up a prescription and wandered into the computer section, where I found myself impulse-buying a href='http://dvforge.com/themousebt.shtml'The Mouse BT/a from some outfit ... -- Henri Sivonen [EMAIL PROTECTED] http://iki.fi/hsivonen/
Re: PaceXhtmlNamespaceDiv
On Feb 7, 2005, at 22:58, Sam Ruby wrote: If you are opposed to this pace, then what div element? If the pace does not get through, it is still permissible to put a div in there as part of the content. In fact, either way it is permissible to add meaningless extra divs, since a div can nest in a div. -- Henri Sivonen [EMAIL PROTECTED] http://iki.fi/hsivonen/
Re: PaceStopArguingAboutSlidingWindowsAndCurrentStateEnoughAlready
On Tue, 08 Feb 2005 10:40:43 +, Bill de hÓra [EMAIL PROTECTED] wrote: Henry Story wrote: If you just want to stick to syntax, then please leave the pace as it is. Don't try to impose a model through syntax and then argue that people can't argue about the model that you are surreptitiously trying to introduce. Henry, I have no idea what you are talking about. I think all Henry's referring to is the implicit model - only so much is made explicit in the spec. There's the obvious containership semantics of XML, there are also plenty of assumptions being made about server/client architectures. Bits over the wire are useless on their own, when semantics are to be attached to them there is benefit in them being standardised through specs. However even if there was the will to define a model, I can't see it happening in the time frame for Atom 1.0. Getting something in an I-D later for RDF-based interop should benefit the core, even without tight spec coupling. But don't let's kid ourselves what we have right now is much more than a syntax and a model with ArchitectureByImplication [1]. 10/10 for the Pace title, btw ;-) Cheers, Danny. [1] http://c2.com/cgi/wiki?ArchitectureByImplication -- http://dannyayers.com
Re: PaceLangSpecific
On Feb 8, 2005, at 10:43, David Powell wrote: text/plain can have a Content-Language header though - is that compatible with xml:lang? For practical purposes, yes. In theory, the semantics are different. xml:lang specifies the language of the content but Content-Language describes the language of the intended audience. -- Henri Sivonen [EMAIL PROTECTED] http://iki.fi/hsivonen/
Re: PaceProfile
Robert Sayre wrote: Bill de hÓra wrote: The problem is that switching on the content of an element/attribute is Atom's get out of jail card wrt extensibility. It is the default Atom extensibility model, as it's the only game we have to play that doesn't involve screwing about with the meaning of existing core data items or adding new core items. Allowing people to add elements in other namespaces under atom:feed or atom:entry and calling that extensibility is like saying a new carpet in my living room is an extension to my house - it's a crashingly weak approach. So, is that a +1 or a -1 on the profile concept? [You mean we have to decide?!?. Now!?!] +1 on the concept. I've seen enough cases in the last week to suggest it's useful. -1 on @profile - use an @rel to hold the content instead. I'm not sure whether atom:feed should get an @rel or whether we should use atom:feed/atom:[EMAIL PROTECTED] cheers Bill
Re: PaceXhtmlNamespaceDiv
Sam Ruby wrote: Bill de hÓra wrote: Sam Ruby wrote: If this Pace is not adopted, the following predictions can be made: 1) Graham (who uses proper XML tools) will have to do more work. I'd like to see a concrete example where this is a problem. As far as I can tell, the content construct itself can be considered the container, so whether or not a mandatory DIV element is present, there will always be a useable container element. 2) Tim (who uses string concatenation) will have to do more work. Nothing changes for Tim, he can continue to produce the output he's producing currently. 3) More feeds will be harder to read (that's why I asked you to experiment with alternate serializations. Whether something is easier to read seems to be a matter of taste: I certainly prefer a globally scoped XHTML namespace declaration, and no additional DIV elements. 3) More feeds will be invalid (content in atom namespace) Perhaps I misunderstand... but this shouldn't result in invalid Atom feeds ever - content areas should be able to hold any-namespace not any-namespace-atom-namespace. Worst case is mangled content when the content is lifted out using namespace aware tools. In other words, the container markup format is just dandy, but the content they carry is potentially trashed. If we condone default namespaces this is what we can expect to happen. We discussed warning people about this broken piece of XML technology last year and it was punted to an Implementors Guide - I'm somewhat unsympathetic now if we find ourselves bitten. Perhaps I overreached with the word invalid, but I am of the opinion that if the type is XHTML that the content should be an xthml fragment. atom:b and atom:strong elements are examples of things which one would not expect to find in xhtml. Yes, but there are many other things people may get wrong when producing Atom. In particular, I would tend to trust those who do generate XHTML instead of HTML to get namespace declarations right as well. Below are some comments that I just added to the Pace: - Requiring the namespace declaration on a particular element means (a) profiling XMLNS, (b) defeating potential space optimizations by having the namespace declaration only once, and (c) breaks XML toolkits that do not provide full control over where namespace declarations appear. - if this pace gets accepted, I would ask for the same DIV container element for HTML content for reasons of symmetry. Best regards, Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Re: PaceXhtmlNamespaceDiv
Julian Reschke wrote: Sam Ruby wrote: Julian Reschke wrote: Anne van Kesteren wrote: Henri Sivonen wrote: -1 on PaceXhtmlNamespaceDiv -1 from me as well. It is hack which might be useful for publishing systems (and perhaps aggregators) who do not use the right tools to generate a valid Atom file anyway. Same here: -1 Can I get one of you three to mock up what Tim's feed should look like? http://www.imc.org/atom-syntax/mail-archive/msg12902.html - Sam Ruby I'm not sure I understand this request. We're not asking Tim or anybody else not to use div elements, we're asking not to be forced by the spec to select a specific way to emit XHTML when many others do as well. So, this is a -1 on forcing feed creators to use a very specific serialization format. This Pace does *not* force feed creators to use a very specific feed format. Anne had this right... if this Pace is adopted, then the div is part of the format. Otherwise, it is part of the content. In other words, if Tim's content has a div element that he wishes to syndicate, he would simply nest that div. This would be rare. As it stands, the content that Tim is syndicating does not match the content on his site. - Sam Ruby
RE: PaceHeadless
James M Snell wrote: My preference would be a link based alternative. feed ... entry ... link rel=feed href=... / /entry /feed I'm tired of arguing this one, so, I'm just going to say this one more time and leave it at that. Linking to the feed is not an acceptable solution. It must be possible to embed feed metadata in an entry in a feed and in an Entry document. Users and their news aggregators expect to have access to source feed title, author, etc. when entries or lists of entries are displayed. If the feed metadata is not in the entries, then it will have to be fetched before entries can be displayed to the user. Thus, we should expect that whenever a feed is received that contains links to feeds, the aggregators will immediately generate a storm of HTTP request to pull down the full feeds which are linked to simply in order to extract the feed titles and other metadata. The result will be bursts of network traffic. Most of the bandwidth consumed will be an absolute waste. (i.e. Many feeds in the wild today are as large as 100K bytes. You're suggesting a design that requires all 100K bytes to be pulled down in order to extract a few bytes of title data. This is silly.) If Atom drops HeadInEntry (or the alternative equivalent mechanisms such as feeder) and replaces it with a link to feed, we at PubSub will simply not be able to use Atom as defined. Other providers of aggregators, search engine results, synthetic feeds, etc. will come to the same conclusion in time. Have a good day. I'm sure you'll all be pleased to know that I won't be bothering you about this in the next few days. Do what you will... bob wyman
Re: PaceXhtmlNamespaceDiv
Sam Ruby wrote: Nothing changes for Tim, he can continue to produce the output he's producing currently. What Tim is syndicating does not match the content on his site. Without this Pace, the div element would need to be considered part of the content. What difference does this make in practice? HTML defines DIV as... These elements define content to be inline (SPAN) or block-level (DIV) but impose no other presentational idioms on the content. (http://www.w3.org/TR/html401/struct/global.html#edef-DIV) 3) More feeds will be harder to read (that's why I asked you to experiment with alternate serializations. Whether something is easier to read seems to be a matter of taste: I certainly prefer a globally scoped XHTML namespace declaration, and no additional DIV elements. Fair. However, a globally scoped XHTML namespace declaration will require every xhtml tag to be explicitly namespaced. (unless we make it the default namespace, which usually won't make sense). - Requiring the namespace declaration on a particular element means (a) profiling XMLNS, (b) defeating potential space optimizations by having the namespace declaration only once, and (c) breaks XML toolkits that do not provide full control over where namespace declarations appear. Nothing in this pace requires such a declaration. When a Text construct or atom:content's type is XHTML, require it to have a single xhtml:div as a child, and require that div to declare the XHTML namespace. Am I looking at the wrong pace? (http://www.intertwingly.net/wiki/pie/PaceXhtmlNamespaceDiv) - if this pace gets accepted, I would ask for the same DIV container element for HTML content for reasons of symmetry. Are you suggesting that the following would need to be required for symmetry? lt;divgt; ... lt;/divgt; Yes. Suggesting this seems petty. Best regards, Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Re: PaceXhtmlNamespaceDiv
On Feb 8, 2005, at 15:59, Julian Reschke wrote: When a Text construct or atom:content's type is XHTML, require it to have a single xhtml:div as a child, and require that div to declare the XHTML namespace. Am I looking at the wrong pace? (http://www.intertwingly.net/wiki/pie/PaceXhtmlNamespaceDiv) The abstract no longer matches the proposal. This seems to cause confusion. -- Henri Sivonen [EMAIL PROTECTED] http://iki.fi/hsivonen/
Re: PaceXhtmlNamespaceDiv
Julian Reschke wrote: - Requiring the namespace declaration on a particular element means (a) profiling XMLNS, (b) defeating potential space optimizations by having the namespace declaration only once, and (c) breaks XML toolkits that do not provide full control over where namespace declarations appear. Nothing in this pace requires such a declaration. When a Text construct or atom:content's type is XHTML, require it to have a single xhtml:div as a child, and require that div to declare the XHTML namespace. Am I looking at the wrong pace? (http://www.intertwingly.net/wiki/pie/PaceXhtmlNamespaceDiv) I have just updated the Pace to remove from the abstract text which is no longer reflected in the proposal. - Sam Ruby
Re: type=HTML
Julian Reschke wrote: (http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.3.1.1) The spec currently says: 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 lt;br. The HTML markup SHOULD be such that it could validly appear directly within an HTML DIV element. Receiving software which displays the content MAY use the markup to aid in displaying it. Is there anything that we can say about what recipients should do if they are not prepared to tag-soup-parse HTML content (such as something based on XSLT1 in Mozilla or running in a size-constrained environment (does MIDP come with an HTML parser)? Skip the entry? Do not display the content? Display the content including the escaped markup as plain text? I would suggest stripping the tags. In Perl, something like this: s/.*?//g Shouldn't we at least give content producers the hint that producing XHTML content is preferred over HTML? (sorry if I'm opening a can of worms here) Depending on the target environment, stripping the elements in XHTML may also be appropriate. - Sam Ruby
RE: PaceHeadless
--On Tuesday, February 08, 2005 08:39:42 AM -0500 Bob Wyman [EMAIL PROTECTED] wrote: Linking to the feed is not an acceptable solution. It must be possible to embed feed metadata in an entry in a feed and in an Entry document. +1 The feed document *must* be standalone. Everything required to interpret the feed has to be in the feed. wunder -- Walter Underwood Principal Architect Verity Ultraseek
Re: PaceHeadless
Well, I ain't gonna argue the point, but I'm going to stick by the assertion that feeder/head is ugly. Any use of this stuff I plan to make can live equally well with either approach. - James M Snell Walter Underwood wrote: --On Tuesday, February 08, 2005 08:39:42 AM -0500 Bob Wyman [EMAIL PROTECTED] wrote: Linking to the feed is not an acceptable solution. It must be possible to embed feed metadata in an entry in a feed and in an Entry document. +1 The feed document *must* be standalone. Everything required to interpret the feed has to be in the feed. wunder -- Walter Underwood Principal Architect Verity Ultraseek
Re: PaceArchiveDocument
On 8 Feb 2005, at 12:14 am, Eric Scheid wrote: PaceArchiveDocument -1 this looks like a backdoor to feeds in feeds. -1, agreed. Graham
Re: PaceDatesXSD
-1 on the regex. It's completely unreadable and hides whatever additional constraints it adds. Write those down in English please. Graham
Re: type=HTML
Sam Ruby wrote: Julian Reschke wrote: (http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.3.1.1) The spec currently says: 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 lt;br. The HTML markup SHOULD be such that it could validly appear directly within an HTML DIV element. Receiving software which displays the content MAY use the markup to aid in displaying it. Is there anything that we can say about what recipients should do if they are not prepared to tag-soup-parse HTML content (such as something based on XSLT1 in Mozilla or running in a size-constrained environment (does MIDP come with an HTML parser)? Skip the entry? Do not display the content? Display the content including the escaped markup as plain text? I would suggest stripping the tags. In Perl, something like this: s/.*?//g Thanks. Are we 100% confident that whatever results from that replacement can be safely embedded? For instance, what about script tags? Can they contain potentially dangerous code that would execute without being referenced from somewhere? Shouldn't we at least give content producers the hint that producing XHTML content is preferred over HTML? (sorry if I'm opening a can of worms here) Depending on the target environment, stripping the elements in XHTML may also be appropriate. Sure, but for XHTML, the XML parser already contains the necessary machinery. Anyway, the spec offers to alternatives (HTML and XHTML) that cover similar use cases. I think it would be good if it made a recommendation at least for those cases, where the producer already has XHTML content. Best regards, Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Re: PaceDatesXSD
/ Graham [EMAIL PROTECTED] was heard to say: | -1 on the regex. It's completely | unreadable and hides whatever | additional constraints it adds. Write | those down in English please. Well, how about English and the regex? I'm worrying about interoperability here. There's considerable pressure to use RFC 3339, but I can't think of any practical, interoperable way to use RELAX NG or W3C XML Schema to constrain the value of Date Constructs to RFC 3339. (I could do it by defining my own data type in RELAX NG, but that wouldn't be interoperable; I could do it by using just xsd:dateTime, but that wouldn't be constraining enough.) I suppose I could just use the combination of xsd:dateTime and the regular expression in my schema to implement the prose if we took the regex out of the spec. *shrug* It's been a long, hard day and I don't have any fight left in me. Given that I'm reasonably confident that xsd:dateTime+regex is isomorphic to the set of RFC 3339 date-times that we want to allow, I'll accept whatever the group decides. Be seeing you, norm -- Norman Walsh [EMAIL PROTECTED] | We learn from experience that not http://nwalsh.com/| everything which is incredible is | untrue.--Cardinal De Retz pgp0ZHDBcLdRp.pgp Description: PGP signature
Re: type=HTML
At 23:36 05/02/08, Julian Reschke wrote: Shouldn't we at least give content producers the hint that producing XHTML content is preferred over HTML? (sorry if I'm opening a can of worms here) I'd be very much in favor of that. The first step is to order the sections so that XHTML comes first. I have suggested this before. This is very close to editorial, but can already give some hint. The second is to add a sentence such as this: Content producers that can produce both XHTML content and HTML content SHOULD produce XHTML content. Regards,Martin.
Re: PaceXhtmlNamespaceDiv
At 22:59 05/02/08, Julian Reschke wrote: http://www.intertwingly.net/wiki/pie/PaceXhtmlNamespaceDiv I have looked at this pace only just very recently, after following the discussion. So I first want to make sure I get the current status of this proposal right. As I currently read it, it does: 1) Require an xhtml:div as the only direct child of content of type XHTML 2) Not limit the placement of namespace declarations in any way above and beyond those given in the Namespace spec. 3) Not require any specific namespace prefixes. If 2) and 3) are correct, I can live with this proposal. Anything changing 2) or 3), as may have been previously in this Pace, would get something like a -2 from me. Specs, in particular such fundamental ones as XML Namespaces, are there to be used as is, not to be tweaked. As for 1), I could live with it, but the rationale given for it in the current version says: Given that even we often forget when writing examples to declare the XHTML namespace for XHTML text constructs and content elements, it seems likely that people producing actual feeds will forget to do so unless the requirement to do so is stated prominently and unambiguously. This doesn't seem to match the proposal, where Namespace declarations are only used in the examples, but not mentioned in the text. So while (as said above) I can live with 1), insisting on 1) without a better rationale doesn't seem to make sense to me. If the concern expressed in the rationale is important (and I can agree it is), then addressing this concern can be done in less constricting ways, i.e. by replacing the requirement for a div with something like: Note: It is important to make sure that correct namespace declarations for XHTML are present. One way to do this is by using an xhtml:div element as the content of the atom:content element and specifying the XHTML namespace on that div element. Here are some examples: ... [use proposed examples] There are other ways to declare the namespace URI for XHTML content; this specification does not limit the placement of such declarations in any way. Regards, Martin.
Re: PaceXhtmlNamespaceDiv
On 9/2/05 3:39 PM, Martin Duerst [EMAIL PROTECTED] wrote: Note: It is important to make sure that correct namespace declarations for XHTML are present. One way to do this is by using an xhtml:div element as the content of the atom:content element and specifying the XHTML namespace on that div element. Here are some examples: ... [use proposed examples] There are other ways to declare the namespace URI for XHTML content; this specification does not limit the placement of such declarations in any way. +1
