Re: Difference of TEXT and XHTML?
On Wed, 26 Jan 2005 17:03:09 -1000 (HST), Lucas Gonze [EMAIL PROTECTED] wrote: Then my point is moot as long as XHTML inline content may be XHTML 1.0 Transitional. A second argument that inline XHTML may be XHTML 1.0 Transitional is that it satisfies the need for well-formed XML. You do whatever you please, of course, but HTML and XHTML is not supposed to be used for formatting, but for structure and semantics. That's why font et al has been dropped from XHTML 1.1, 2.0 and the Strict DTD's (which is recommended to use over the Transitional ones). Because having control over presentation is the main reason to format content as HTML. Uhm. Okay. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: Difference of TEXT and XHTML?
On 27/1/05 6:23 PM, Henri Sivonen [EMAIL PROTECTED] wrote: But type='TEXT' is only a degenerate case of type='XHTML' (type='XHTML' with only text content). What value does type='TEXT' add to the format except the ability of feedvalidator.org to detect cases where there are element children although the author claims there are not, which suggests an authoring error? Does type='TEXT' intentionally exist only to add this feedvalidator.org value? maybe it exists so I can write a title which looks like this I hate the blink tag which is the plain text rendition, or if I wanted to code it in html/xhtml it would be I hate the lt;blinkgt; tag and then applying XML escaping ... would be the following? ... title type='TEXT I hate the lt;blinklt; tag/title title type='HTML I hate the amp;lt;blinkamp;lt; tag/title title type='XHTMLI hate the amp;lt;blinkamp;lt; tag/title e.
Re: PaceAttributesNamespace is *not* about syntax!
Thanks for the reply, Sam. I think the misunderstanding has mostly to do with the fact that we have similar but slightly different aims. We should try to clearly establish our respective aims and find the points we have in common, so that we can agree to solve the points we have in common quickly and easily. On 27 Jan 2005, at 03:39, Sam Ruby wrote: Henry Story wrote: On 26 Jan 2005, at 15:03, Sam Ruby wrote: [...] But, now lets examine the statement proposed in PaceAttributeNamespace. It essentially alerts producers of something that that they need to be aware of. Now a quesion: what do they need do different with the knowledge that the RDF mapping does this? I would assert the answer to this question is nothing. Meaning that this particular statement is not needed. Again, no issue with the mapping. No issue with describing the mapping alongside with the actual mapping. I think your assertion is wrong. If they are consuming or producing extended Atom [1] they will know exactly what these extensions are referring to. It won't affect in the least consumers of simple, non extended Atom, but it will greatly help consumers and producers of extended atom. Now if you don't care about making their lives easier, then you have nothing to worry about in this pace. If you do, like I and many others, then this will be very helpful. It seems to me that you are both misunderstanding and mischaracterizing what I am saying. Furthermore, in other emails, I sense a confusion between RDF (which is a model) and RDF/XML (which is a syntax). No worry. I think we all know the difference there, but the language does lend itself to confusion. I am in favor of AtomAsRDF (as a way to model this data). I am opposed to AtomAsRDFXML (as a syntax for expressing this model). Ok. I am in favor of AtomAsRDF(Model) too. But I am trying to go a little further to AtomAsRDFXML (as you put it) because - The spec can very nearly already be interpreted that way - defining another mapping from xml to RDF, though possible, is a lot of work, and we just don't have the time - it will allow for the easiest way to explain extensibility of Atom So though I think (and I have recently myself tried out some ideas on this subject) there may be some general mapping rule from xml to rdf that are much closer to the general users intuitions about xml, I think that when the xml is written as atom currently (nearly) is, we have something that does map to a graph and that will map to the same graph than any more intuitive mapping than rdf/xml would. If anybody is up to the task, I am for inclusion of prose into the standard describing how one is to interpret Atom feeds as RDF. Any such mechanism that accomplishes this will, by necessity, need to specify what namespace is used in the URIs used to define relationships. Well I liked your idea of adding a special section to the spec on how to interpret atom as rdf/xml, perhaps as part of the extensibility section. My feeling is that would be best if it explains how atom can be seen to be rdf/xml, because then explaining extensibility will be very easy: any atom document with foreign name spaced attributes or elements must also be an rdf/xml document when so interpreted And we then leave the complexity of that statement to the other specs out there. PaceAttributeNamespace does not do that. All it says is is that a given namespace may be used. For what purpose such a statement is made is entirely unclear. By contrast, a precise statement to the effect of how RDF aware tools MUST interpret Atom feeds if they are to interoperate is both clear and useful. Ok. Well I think we are really thinking very similar thoughts here. I would just add that we should try to see if the RDF/XML interpretation of Atom works out, because that will vastly reduce the amount of work we need to do in explaining the interpretation. (interpretation is an excellent word!) Henry Story - Sam Ruby
Re: PaceEnclosuresAndPix status
On 27/1/05 7:26 PM, Henri Sivonen [EMAIL PROTECTED] wrote: I'd prefer an element, because the nature of the favicon reference is not that a user would want to manually follow the link. That is: icon src='...' or icon href='...' I've drafted a Pace for this... http://www.intertwingly.net/wiki/pie/PaceIconAndImage This competes with parts of PaceEnclosuresAndPix, and so have also written PaceLinkEnclosure which simply strips out the Pix part. http://www.intertwingly.net/wiki/pie/PaceLinkEnclosure e.
Re: Difference of TEXT and XHTML?
On Jan 27, 2005, at 09:41, Tim Bray wrote: OK, you've advanced this argument several times now. If you want to change the Atom format to remove type=TEXT, write a Pace (it'll be short easy) and see if you can build consensus. http://www.intertwingly.net/wiki/pie/PaceTypeTextRedundant I have to warn you that the process by which we got to consensus on the current setup was long, arduous, and involved a huge volume of email, and you may get -1's based on people just not wanting to revisit this space. Sure, the current version is better than the mode/type stuff. -- Henri Sivonen [EMAIL PROTECTED] http://iki.fi/hsivonen/
Re: PaceAttributesNamespace is *not* about syntax!
On Wed, 26 Jan 2005 21:39:23 -0500, Sam Ruby [EMAIL PROTECTED] wrote: PaceAttributeNamespace does not do that. All it says is is that a given namespace may be used. For what purpose such a statement is made is entirely unclear. Ok, maybe a little more explanation is needed in the Pace. The purpose is to provide global names to the relations expressed by the attributes. Global naming leads to global network effects. http://www.w3.org/TR/2004/REC-webarch-20041215/#identification Cheers, Danny. -- http://dannyayers.com
Re: PaceAttributesNamespace is *not* about syntax!
Henry Story wrote: Graham the Robot [1], when real people come and ask me something I'll talk to them. Rudeness objection. I'm seeing genuine questions; fobbing them off (as above) is not helping your case. cheers Bill
Re: PaceAttributesNamespace is *not* about syntax!
Danny Ayers wrote: On Wed, 26 Jan 2005 21:39:23 -0500, Sam Ruby [EMAIL PROTECTED] wrote: PaceAttributeNamespace does not do that. All it says is is that a given namespace may be used. For what purpose such a statement is made is entirely unclear. Ok, maybe a little more explanation is needed in the Pace. The purpose is to provide global names to the relations expressed by the attributes. Global naming leads to global network effects. http://www.w3.org/TR/2004/REC-webarch-20041215/#identification So... define the cases where it MUST be used ... and how ... in order to achieve interoperability. If the desire is to provide global names to the relations expressed by the attributes, then it would make sense to describe what namespace MUST be used for such relationships. Perhaps in the portion of the document which describes how one is to infer such relations from the raw xml attributes. - Sam Ruby
PaceIconAndImage, and PaceLinkEnclosure
resending with more appropriate subject line, just in case these two new paces got lost in the thread... I'd prefer an element, because the nature of the favicon reference is not that a user would want to manually follow the link. That is: icon src='...' or icon href='...' I've drafted a Pace for this... http://www.intertwingly.net/wiki/pie/PaceIconAndImage This competes with parts of PaceEnclosuresAndPix, and so have also written PaceLinkEnclosure which simply strips out the Pix part. http://www.intertwingly.net/wiki/pie/PaceLinkEnclosure e.
Re: Difference of TEXT and XHTML?
I only noticed this thread after looking at the same material through RDF-tinted spectacles. A question for the schema mavens: is there *any* clear way of describing the difference between the three content types (TEXT/HTML/XHTML) in a machine readable fashion? In the Rosy-tinted Description Framework, if the type could be fully expressed using XML Schema datatypes, the Atom content element could map nicely onto a XSD-datatyped literal. Problem is I couldn't see any obvious way of distinguishing HTML from TEXT, as the former would be escaped anyway. So in effect for RDF I think the content would have to appear as a literal, with the type as a kind of annotation, the easiest RDF/XML version being something like: atom:contentConstruct atom:contentyodel-ay-ey-oo/atom:content atom:datatypeTEXT/atom:datatype /atom:contentConstruct Cheers, Danny. On Thu, 27 Jan 2005 14:48:44 +, Graham [EMAIL PROTECTED] wrote: On 27 Jan 2005, at 1:34 pm, Sam Ruby wrote: http://www.intertwingly.net/wiki/pie/PaceTypeTextRedundant There are cases where explicit is better than implicit. Yes. It's more a psychological rather than a technical difference, but I think it's important (it's like the difference between ASCII and UTF-8). -1 on the pace. Graham (PS Are line breaks in Text mode honored?) -- http://dannyayers.com
Re: PaceEnclosuresAndPix status
On Wednesday, January 26, 2005, at 10:40 PM, Eric Scheid wrote: so, icon ... or favicon. I prefer the latter. I prefer the former. favicon = favorites icon. I think favorites is a bad name for bookmarks--a person's reason for bookmarking something (or in the case of Atom, subscribing to a feed) may not have anything to do with how much they like it. And besides, the icon is displayed (in some browsers at least) when you're viewing the page, not just when it's bookmarked. I'd rather not propagate the use of the term. Let's just call it what we know it is--an icon.
Re: PaceAttributesNamespace is *not* about syntax!
On 27 Jan 2005, at 15:28, Bill de hÓra wrote: Rudeness objection. One reaps what one sows. [1] I'm seeing genuine questions Since you are asking, I'll answer them. On 26 Jan 2005, at 4:37 pm, Henry Story wrote: I think your assertion is wrong. If they are consuming or producing extended Atom [1] they will know exactly what these extensions are referring to. It won't affect in the least consumers of simple, non extended Atom, but it will greatly help consumers and producers of extended atom. What will? To what does these extensions refer? How will it help who? Consider the problem of creating extensions to Atom. You are adding a new vocabulary to the current atom vocabulary, so you will have non atom name spaced elements or attributes in your extended atom document. feed entry titleAtom Robots run amok/title link href=http://example.org// my:illustration my:href=http://bblfish.net/blog/img.jpg; ... /entry /feed We are all agreed about what the above document means, stripped of the my:illustration tag. Parsers that only wish to concern themselves with those striped documents will have no trouble. The spec clearly specifies what is what. The problem is to clearly specify how extended atom documents like the one above are to be written consistently, so that they can be interpreted correctly, the way the writer of the document intended them to be. To what does these extensions refer? These extensions refer to attributes such as my:href in the example above. How will it help who? The problem is that attributes in atom are not namespaced. If they were then it would be easy to interpret the above document as an rdf document. An rdf document has very clearly specified semantics. Having these clearly specified semantics is very helpful to extension writers and consumers. The details of how it will help are much more difficult to explain in a short e-mail such as this. A hint is contained in the word onotology. This has to do with Objects. And there is a very strong relationship between OO programming and what is being proposed here. The benefits of OO programming are the same benefits we stand to gain here: it makes it much easier to create elements and specify how they can be combined. But it would perhaps be best to work through an example to help show how this works. Does this help? Henry Story [1] http://www.imc.org/atom-syntax/mail-archive/msg12038.html
Re: Difference of TEXT and XHTML?
Graham wrote: On 27 Jan 2005, at 1:34 pm, Sam Ruby wrote: http://www.intertwingly.net/wiki/pie/PaceTypeTextRedundant There are cases where explicit is better than implicit. Yes. It's more a psychological rather than a technical difference, but I think it's important (it's like the difference 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: Difference of TEXT and XHTML?
On Jan 27, 2005, at 17:50, Tim Bray wrote: On Jan 27, 2005, at 4:46 AM, Eric Scheid wrote: however, the spec says: The content SHOULD be XHTML text and markup that could validly appear directly within an xhtml:div element. which could lead others to make the same mistake I must have made. The easiest way to solve this, I think, is with examples. Avoiding the word markup would also help avoiding any associations with unparsed source. -- Henri Sivonen [EMAIL PROTECTED] http://iki.fi/hsivonen/
Re: Multiple content allowed?
Bill de hÓra wrote: Norman Walsh wrote: Someone sent me this, noting that it was not valid according to the grammar I posted. He thought it was legal according to the spec, and I'm not sure. What say you? My first thought is that unless there a use-case for multiple content blocks, you've found a bug in the spec. http://www.atompub.org/2005/01/10/draft-ietf-atompub-format-04.html#rfc.section.5.12 atom:entry elements MUST contain zero or one atom:content elements. PaceReformedContent3 made multiple content elements invalid. I wonder why that example couldn't use an xhtml summary element. Robert Sayre
Re: Difference of TEXT and XHTML?
Antone Roundy wrote: On Thursday, January 27, 2005, at 12:47 AM, Eric Scheid wrote: On 27/1/05 6:23 PM, Henri Sivonen [EMAIL PROTECTED] wrote: But type='TEXT' is only a degenerate case of type='XHTML' (type='XHTML' with only text content). What value does type='TEXT' add to the format except the ability of feedvalidator.org to detect cases where there are element children although the author claims there are not, which suggests an authoring error? Does type='TEXT' intentionally exist only to add this feedvalidator.org value? maybe it exists so I can write a title which looks like this I hate the blink tag which is the plain text rendition, or if I wanted to code it in html/xhtml it would be I hate the lt;blinkgt; tag and then applying XML escaping ... would be the following? ... title type='TEXT I hate the lt;blinklt; tag/title title type='HTML I hate the amp;lt;blinkamp;lt; tag/title title type='XHTMLI hate the amp;lt;blinkamp;lt; tag/title In a message sent off-list to me last June, which I no longer have, but referred to in a message on list[1], Sam said that: content type=inline-xhtml amp;copy; /content should be rendered copy;, not as a copyright symbol (because it's not in the XHTML namespace, ie. it's not this:) I did say that that's how it should be rendered (I forwarded to you my original email) but the reason has nothing to do with namespaces. content type=inline-xhtml span xmlns=http://www.w3.org/1999/xhtml;amp;copy;/span /content ...which seems to suggest that the above XHTML example should be: title type=XHTMLI hate the lt;blinkgt; tag/title yes or: title type=XHTMLspan xmlns=http://www.w3.org/1999/xhtml;I hate the amp;lt;blinkamp;gt; tag/span/title no Clearly some examples ARE in order. - Sam Ruby
Re: Mandatory method of specifying XHTML namespace?
On Jan 27, 2005, at 19:30, Antone Roundy wrote: Given how common it is even for us, when posting examples of content type=XHTML without declaring the XHTML namespace, might it be a good idea to specify a mandatory method of declaring the XHTML namespace to ensure that implementors don't forget? +1 That should be obvious. If the value of type is XHTML, the content of the Text construct MUST be a single xhtml:div element -1 gratuitous element cruft. The text construct element itself serves as a container. which MUST declare the XHTML namespace, either as the default namespace or with a namespace prefix -1 Atom should not micro-manage how and on which elements namespace declarations appear. Feed in the wild that declares the namespaces on root: http://macsanomat.fi/atom -- Henri Sivonen [EMAIL PROTECTED] http://iki.fi/hsivonen/
Re: PaceAttributesNamespace is *not* about syntax!
Danny Ayers wrote: Yes and no - there is demand for this kind of thing, is the RSS 1.0 community the same as the RDF community? There's a lot of additions around there... Whatever, even with RSS 2.0 there's Easy News Topics and all the stuff associated with media (enclosures + Yahoo's extensions) as good examples. Is the RSS1.0 community relevant, given RSS1.1? I'm sincere in asking this. My concern there is with extension development outside of the RDF community. Without some uniform interpretation of the attributes outside of the context of an Atom document, there's scope for unwanted interactions. Assigning the things global names (URIs), even if they aren't explicitly expressed in Atom documents seems a low cost solution. Does this help? Yes, but I think it can be dealt with as outlined above, unless I'm missing something. Non-RDF extensions. As I've said, I'm not seeing the demand for uniform evaluation outside an RDF context. cheers Bill
I-D ACTION:draft-ietf-atompub-format-05.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Atom Publishing Format and Protocol Working Group of the IETF. Title : The Atom Syndication Format Author(s) : M. Nottingham, R. Sayre Filename: draft-ietf-atompub-format-05.txt Pages : 37 Date: 2005-1-27 This document specifies Atom, an XML-based Web content and metadata syndication format. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-05.txt To remove yourself from the I-D Announcement list, send a message to [EMAIL PROTECTED] with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username anonymous and a password of your e-mail address. After logging in, type cd internet-drafts and then get draft-ietf-atompub-format-05.txt. A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: [EMAIL PROTECTED] In the body type: FILE /internet-drafts/draft-ietf-atompub-format-05.txt. NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the mpack utility. To use this feature, insert the command ENCODING mime before the FILE command. To decode the response(s), you will need munpack or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with multipart MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ftp://ftp.ietf.org/internet-drafts/draft-ietf-atompub-format-05.txt
Re: PaceIconAndImage
On 28/1/05 4:03 AM, Bob Wyman [EMAIL PROTECTED] wrote: Also, why limit this to feed/head, and not entry? So that Atom feeds will be easily convertible to RSS 2.0? Converting *to* RSS 2.0 shouldn't be a goal or even a consideration in any Atom related discussions. Only conversion *from* RSS 2.0 is interesting. If Atom is guaranteed to be convertible both to and from RSS 2.0 then Atom can never be more than RSS 2.0 and a great deal of the effort and goodwill that has gone into Atom would be a complete waste of time. but we shouldn't get spiteful about it. If it doesn't matter either way on some point, why not allow compatibility? I'm saying it should be a consideration and possibly even an assumption, but remembering that if there is a good reason to go another route (and break compatibility) then that trumps the case. Lets not be incompatible for incompatibilities sake.! e.
Re: PaceIconAndImage
On 28/1/05 3:08 AM, Antone Roundy [EMAIL PROTECTED] wrote: Also, why limit this to feed/head, and not entry? So that Atom feeds will be easily convertible to RSS 2.0? Certainly there are ways to add images to entries in RSS 2.0, though not icons (as far as I'm aware), but I don't think that's a big deal. RSS compatibility is one reason, as described in the rationale. Another is that we're not talking a generic image here, we're talking about some kind of special badge or branding image, which doesn't make sense for entries. You can still add whatever images (and other resources) you want to an entry with link. Maybe we should rename the image element to logo? Which brings me to PaceIconAndImage--the pace itself makes forbids putting one of the attributes of Link Constructs in the elements (@rel). Another of them (@href) is not accurately descriptive of what it would be used for. Another of them (@title) doesn't seem very useful for icon (unless for accessibility--do people more involved in accessibility issues think that's needed--that it's going to be used to say anything more than xyz.com's icon?) Is it really appropriate to call this a Link Construct? I used a Link construct to keep word count down. Otherwise we'd need to define an extra four attributes which have exactly the same names as those in Link Constructs, which seemed like unnecessary wordage. It would really bloat the spec. Saying instead that it's a Link construct where one attribute is meaningless is much easier to not only write, but also to read. @rel - yeah, I wrestled with that myself too, but then remember that other elements place additional constraints on Link constructs elsewhere (eg. 4.2.2). Also, @rel is a MAY, so it's not like it's totally breaking the template. @href - what ever do you mean here? @title in image certainly might be used for @alt text, the same way it is specced in RSS 2.0. That's why I left @title in. @title in icon could be used for @alt text if the icon is displayed someplace, or more likely simply ignored. The street will find a use for it, or not. e.
Re: PaceAttributesNamespace is *not* about syntax!
On Thu, 27 Jan 2005 20:49:12 +, Bill de hÓra [EMAIL PROTECTED] wrote: Danny Ayers wrote: Yes and no - there is demand for this kind of thing, is the RSS 1.0 community the same as the RDF community? There's a lot of additions around there... Whatever, even with RSS 2.0 there's Easy News Topics and all the stuff associated with media (enclosures + Yahoo's extensions) as good examples. Is the RSS1.0 community relevant, given RSS1.1? I'm sincere in asking this. Dunno really. There are an awful lot of RSS 1.0 feeds out there - you've got one, I've got one. If rss-dev give the green light to 1.1, I'll probably changeover before long, though the extensions (FOAF, Geo) I've got in place aren't likely to change. My concern there is with extension development outside of the RDF community. Without some uniform interpretation of the attributes outside of the context of an Atom document, there's scope for unwanted interactions. Assigning the things global names (URIs), even if they aren't explicitly expressed in Atom documents seems a low cost solution. Does this help? Yes, but I think it can be dealt with as outlined above, unless I'm missing something. Non-RDF extensions. As I've said, I'm not seeing the demand for uniform evaluation outside an RDF context. Outside of the [insert Brayism about architects], demand for uniformity is generally thin on the ground around syndication (guids ring a bell?). But that doesn't reduce its benefits, usually uniformity leads to a net cost reduction, don't you reckon? Standards and all that? Cheers, Danny. -- http://dannyayers.com
Re: Mandatory method of specifying XHTML namespace?
On 28/1/05 7:39 AM, Henri Sivonen [EMAIL PROTECTED] wrote: If the value of type is XHTML, the content of the Text construct MUST be a single xhtml:div element -1 gratuitous element cruft. The text construct element itself serves as a container. but atom:title != xhtml:title also, are there such things as xhtml:copyright, xhtml:info, or xhtml:summary? which MUST declare the XHTML namespace, either as the default namespace or with a namespace prefix -1 Atom should not micro-manage how and on which elements namespace declarations appear. Feed in the wild that declares the namespaces on root: Good point. The declaration of the namespace 'xhtml' can occur elsewhere, and if on the root then it cuts down on needless repetition. e.
Re: PaceIconAndImage
On 28/1/05 10:02 AM, Eric Scheid [EMAIL PROTECTED] wrote: I used a Link construct to keep word count down and now with -05 published there is no generic Link Construct. I'll update the pace with all the necessary extra wordage and bloat. e.
Re: PaceXhtmlNamespaceDiv posted
On Jan 27, 2005, at 22:30, Antone Roundy wrote: I'm not in favor of mandating restrictions, because there are probably legitimate uses for anything we might try to protect people against. The namespace div places restrictions on where namespace declarations appear and, therefore, limits the legitimate use of serializers that take care of namespace declarations. -1 for the pace, still. -- Henri Sivonen [EMAIL PROTECTED] http://iki.fi/hsivonen/
Re: PaceXhtmlNamespaceDiv posted
On Thursday, January 27, 2005, at 10:38 PM, Henri Sivonen wrote: On Jan 27, 2005, at 22:30, Antone Roundy wrote: I'm not in favor of mandating restrictions, because there are probably legitimate uses for anything we might try to protect people against. The namespace div places restrictions on where namespace declarations appear and, therefore, limits the legitimate use of serializers that take care of namespace declarations. -1 for the pace, still. Okay, this one's obviously dead. Let's just make sure we have examples that make how all these things work clear.
Re: Mandatory method of specifying XHTML namespace?
On 28/1/05 4:58 PM, Henri Sivonen [EMAIL PROTECTED] wrote: a:copyright type='XHTML'Copyright 2005 John Doe, h:emall rights reserved/h:em/a:copyright (assuming 'a' to be bound to the Atom namespace and 'h' to the XHTML namespace) is less crufty than a:copyright type='XHTML'div xmlns='http://www.w3.org/1999/xhtml'Copyright 2005 John Doe, emall rights reserved/em/div/a:copyright and this is somewhere in the middle... a:copyright type='XHTML' h:divCopyright 2005 John Doe, emall rights reserved/em/h:div /a:copyright once you have more than just one set of tags like em/em in there. e.
Re: Mandatory method of specifying XHTML namespace?
On Jan 28, 2005, at 01:38, Eric Scheid wrote: On 28/1/05 7:39 AM, Henri Sivonen [EMAIL PROTECTED] wrote: If the value of type is XHTML, the content of the Text construct MUST be a single xhtml:div element -1 gratuitous element cruft. The text construct element itself serves as a container. but atom:title != xhtml:title also, are there such things as xhtml:copyright, xhtml:info, or xhtml:summary? No, but that is not the point. The *Atom* Text constructs work as containers. The div is just cruft. IMO, a:copyright type='XHTML'Copyright 2005 John Doe, h:emall rights reserved/h:em/a:copyright (assuming 'a' to be bound to the Atom namespace and 'h' to the XHTML namespace) is less crufty than a:copyright type='XHTML'div xmlns='http://www.w3.org/1999/xhtml'Copyright 2005 John Doe, emall rights reserved/em/div/a:copyright . Even if you wanted to declare the XHTML namespace on the spot, you could put the declaration on the Atom Text construct. Any feed reader using namespace-aware XML tools properly will have no trouble dealing with the less crufty versions. -- Henri Sivonen [EMAIL PROTECTED] http://iki.fi/hsivonen/
Re: Issues with draft-ietf-atompub-format-04
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. After all, once you support XHTML content in a Gecko-based aggregator in a non-bogotic way (XML DOM to XML DOM copy with platupus filtering), you get MathML for free. -- Henri Sivonen [EMAIL PROTECTED] http://iki.fi/hsivonen/
Re: Issues with draft-ietf-atompub-format-04
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. After all, once you support XHTML content in a Gecko-based aggregator in a non-bogotic way (XML DOM to XML DOM copy with platupus filtering), you get MathML for free. We are not here to standardize eventually. This discussion is a waste of time. Robert Sayre
