Re: Additional 'namespace' attribute on content element?
On Jan 5, 2007, at 09:47, Martin Duerst wrote: So I think that Atom is a bit out on it's egde if it says 'if you don't have a +xml Mime Type, you're not XML'. No, Atom says that if you don't use application/xml or an +xml type, you don't get to use an embedded subtree and your format gets the kind of treatment that non-XML formats get. Atom is quite reasonable here. An XML vocabulary that doesn't have a MIME type that follows the convention *and* doesn't have a namespace is itself a badly-behaved XML vocabulary. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: base within HTML content
On Jan 2, 2007, at 12:40, A. Pagaltzis wrote: * Henri Sivonen [EMAIL PROTECTED] [2007-01-02 01:35]: I hadn't thought that Atom was supposed to use innerHTML parsing. I'd have said that you prepend !DOCTYPE htmltitle/titlediv to what travels in the feed and append /div to it, parse the resulting string and grab the first div in the document order. That will lead to silent data loss if the content is malformed such that it contains an extraneous `/div`. Good point. Prepending !DOCTYPE htmltitle/title and grabbing the contents of body would work better. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: base within HTML content
On Jan 1, 2007, at 22:46, Anne van Kesteren wrote: I suppose you could raise this on the WHATWG list. Asking what happens if you set innerHTML of a div where the setted value has both a base and an a for instance. Interesting. I hadn't thought that Atom was supposed to use innerHTML parsing. I'd have said that you prepend !DOCTYPE htmltitle/ titlediv to what travels in the feed and append /div to it, parse the resulting string and grab the first div in the document order. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: Atom Entry docs
On Dec 13, 2006, at 17:51, Mark Baker wrote: But given that an alternative exists which shouldn't break those servers, why not use it when there's no apparent downside? The downside is that implementations that (quite reasonably) assume that application/atom+xml == feed are also reasonable when they ignore unknown media type parameters. Given the options of a new type or a new parameter, I am +1 on the new type. (Although in general, I don't like the proliferation of application/*+xml types, because apps need to do root sniffing for application/xml anyway.) -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: PaceAutoDiscoveryDraftIsPointless
On Nov 28, 2006, at 22:11, Edward O'Connor wrote: WHAT WG seems like a neutral ground, syndication-format wise, so perhaps they're best positioned to spec feed autodiscovery in a way that makes everybody happy. +1 for leaving speccing this to the WHATWG. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: PaceResurrectAutodiscovery
On Nov 24, 2006, at 10:28, Thomas Broyer wrote: My main problem with autodiscovery is this use case: the following links on an entry page in a blog-like scenario, where comments on the entry are shown at the bottom of the page: link rel=alternate type=application/atom+xml title=A standalone Atom Entry alternate representation, might even be updatable using HTTP PUT / ... 1. the first one should not be seen as a feed link; That ship sailed long ago. For backwards compatibility, UAs will treat links like the one quoted above as feed autodiscovery links-- not as standalone APP editing links. It is too late to apply elegance retroactively. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: PaceResurrectAutodiscovery
On Nov 23, 2006, at 22:42, Henry Story wrote: This is very nice, in that it opens up the possibility of placing good RDF descriptions of these links at the http://www.iana.org/ assignments/relation/, How could new link relations be described in RDF to such a degree that the description would actually be useful for software processing but simple enough to actually be implemented? Is it realistic to have UAs whacking IANA server effectively performing a DDoS on it? as well as making the link relation very extensible (people who want to try out new link relations, can just use their own, unambiguous url). How are full URIs distinguished from strings that need to be appended to http://www.iana.org/assignments/relation/; to obtain the full URI? Are UAs supposed to look for a colon as with XForms input methods? Where is this specified? In practice people seem to want to use one-word link relations even when they are coming up with their own. I would recommend you adopt that too. Perhaps you can even adopt the iana name space. If we could get them to put the appropriate rdf document at that location, people who created/coined new link relations could describe these relations as being superproperties or subroperties of relations the browser already knows, which would allow the browser to partially interpret those. Well, RDF is not viewed that favorably by the WHATWG. Also, the barrier for entry for the IANA registration process is likely too high. (It certainly is for MIME types.) As for using the same namespace, the HTML5 definitions for the link types don't necessarily match the Atom definitions. Recently, a WHATWG-managed registry for HTML5 rel values has been discussed informally. The idea was that conformance checkers could consult an online registry instead of only allowing a fixed list of values or allowing everything. RDF is an overkill for this. Even XMDP isn't the simplest thing that could possibly work. The simplest thing that could possibly work is a GETtable text/plain; charset=utf-8 resource at a well-known URI with one rel value per LF-separated line. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: Forward Compatibility
On Nov 19, 2006, at 04:33, Tse Shing Chi ((Franklin/Whale)) wrote: This means that XHTML 2 contents can be used as follows? content type=xhtml div xmlns=http://www.w3.org/2002/06/xhtml2/; !-- Contents XHTML 2.0 -- /div /content content type=application/xhtml+xml div xmlns=http://www.w3.org/2002/06/xhtml2/; !-- Contents XHTML 2.0 -- /div /content By the way, are they the same? They are not the same and neither is correct. The correct way would be: content type=application/xml html xmlns=http://www.w3.org/2002/06/xhtml2/; head titleThe title of the entry again/title /head body !-- Contents XHTML 2.0 -- /body /html /content But it isn't worthwhile to spend energy on this issue. Browser vendors have been ignoring XHTML 2.0 and now even the W3C itself is moving aside the group that has been working on the XHTML 2.0 spec. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: Forward Compatibility
On Nov 19, 2006, at 12:10, Tse Shing Chi ((Franklin/Whale)) wrote: First of all, the media type should still be application/xhtml +xml for XHTML 2.0, although application/xml or even text/html may be used. RFC 3236 makes it pretty clear that it is for XHTML Family documents in the Modularization of XHTML sense. XHTML 2.0 documents are not XHTML Family documents. They are incompatible documents with a confusing name. I don't think whole XHTML 2.0 document needs to be contained in the content or summary element, it is too complicated. Using the div element is still a suitable way (div is remained in XHTML 2.0 without major changes, http://www.w3.org/TR/xhtml2/mod- structural.html#edef_structural_div) I think. It is not the same div. It is a completely different div in another namespace. That the local names are identical does not make them the same. The Atom spec provides shortcuts for plain text, HTML and XHTML 1.x. That's it. Calling an incompatible language XHTML doesn't help. As far as Atom is concerned, XHTML 2.0 documents get the same treatment as any other XML document that doesn't use the XHTML 1.x namespace. (Yes, I am aware of http://lists.w3.org/Archives/Public/www-html/ 2006Nov/0025 , but that resolution doesn't really make XHTML 2.0 any more likely to be implemented.) For browsers' implementation, in fact, XHTML 1.1 is still not well- supported. CSS 2 is another example of poor implementation by browsers. I do think that Atom should not be easy to change or be updated very frequently. That's why Atom should leave some extents of forward compatibility. If you start from XHTML 1.0 and go forward, you don't end up at XHTML 2.0 but at XHTML5. Embedding XHTML5 in Atom will work out just fine. Forward is here: http://whatwg.org/specs/web-apps/current-work/ -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: Forward Compatibility
On Nov 18, 2006, at 22:06, Nikola Stojanovic wrote: What would then be the purpose of 2005 in the atom namespace xmlns:atom=http://www.w3.org/2005/Atom;? It indicates the year when the URI was minted. It is debatable whether it is a useful purpose, but that's the way the W3C mints URIs. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests
On Jun 28, 2006, at 02:27, James M Snell wrote: That is, what is the exact behavior that a library must perform when a code library has an API like, getContent on the content element. One sane behaviour is to return an org.w3c.dom.DocumentFragment with the deep copies of the children of the namespace div with the xml:base and xml:lang context pushed down on each child. That's a bit awkward, so I guess using a placeholder root element with the xml:base and xml:lang context would make sense, provided that the API doc says that the root is not part of the logical content. This could be emphasized by using a root in a private namespace instead of an XHTML div. (Just to be obnoxious enough to make sure users of the API take note. :-) Or, alternatively, the API could construct a full XHTML nu.xom.Document or org.w3c.dom.Document and thereby unify the return value for type=application/xhtml+xml, type=text/html, type=xhtml and type=html. (Assuming, that is that the library runs TagSoup and automatically converts HTML to XHTML.) Actually, I think this would be the best way. In any case, returning a String as the value of the content means that the library is not fully doing its job when the logical value is an XML document fragment. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests
On Jun 28, 2006, at 23:53, James M Snell wrote: or instance, if I have content xml:lang=endiv xml:lang=fr.../div/content and I drop the div silently, then I've got a problem. Dropping the div shouldn't mean dropping the language and base URL context. You need to communicate those anyway in the case they are inherited from higher up in the document tree. (When the script that generates my feed copies node from a document tree to another, it checks the inherited language of the node being copied. If it differs from the inherited language of the insertion target, the newly inserted copy gets an explicit xml:lang.) -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: Datatype for IRIs in RELAX NG
On Mar 21, 2006, at 11:29, Julian Reschke wrote: maybe it's time that *some* specification adds new datatypes that do *exactly* what RFC3986 and RFC3987 ask for :-) I have a draft spec at http://hsivonen.iki.fi/html5-datatypes/ A snapshot of the reference implementation (which currently lacks the 'language' datatype) is available for testing as part of my validation service: http://hsivonen.iki.fi/validator/ The reference implementation just wraps the IRI library from Jena (pulled from CVS; the new version does not ship in a Jena release, yet). Disclaimer: The datatype library has undergone *very* little testing. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: Error in example ?
On Apr 4, 2006, at 13:36, cedric wrote: In 3.1.1.3 XHTML of http://www.atomenabled.org/developers/syndication/atom-format- spec.php#atom.documents There is example using summary but this is deprecated in atom 1.0 I think. It is not deprecated. See: http://www.atomenabled.org/developers/syndication/atom-format- spec.php#element.summary Actually, there is nothing deprecated in Atom 1.0. There are only things that are in the spec and things that are not in the spec. There is no Atom 0.3. :-) These are not the droids you are looking for. :-) -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Datatype for IRIs in RELAX NG (was: Re: Atom syndication schema)
(Discussion started on atom-syntax, but this is a more general RELAX NG issue, so cross-posting to rng-users.) On Mar 19, 2006, at 09:33, Martin Duerst wrote: At 18:49 06/03/17, Bjoern Hoehrmann wrote: * Martin Duerst wrote: When looking with a microscope, you will find some little differences, because xs:anyURI was described before the IRI spec (RFC 3987) was approved. These differences are: 1) xs:aryURI also allows spaces and a few other ASCII characters that are not allowed in URIs nor in IRIs (but the IRI spec has an escape hatch for such cases). 2) The IRI spec contains many more details than the xs:anyURI description, in particular also some requirements re. normalization. However, some of the requirements in this area of the IRI spec may be lowered or removed in the future because we have received feedback from implementers that there are difficulties to implement these. I agree with Martin that it would be incorrect to use xsd:anyURI here. Sorry, but I never said that it would be incorrect to use xsd:anyURI. I personally think that it should be okay to use xsd:anyURI. The differences are microscopic, and they should become even smaller, or hopefully go away completely, over time. I need datatypes for IRIs in general (relative, absolute or just fragment identifiers) and for absolute IRIs (possibly with a fragment id) in a RELAX NG schema. Is it really the best practice to use xsd:anyURI and sweep the discrepancies under the rug in the hope that future definitions of xsd:anyURI change the meaning of the schema later? Can xsd:anyURI be augmented with a regexp pattern to restrict spaces and a few other ASCII characters in such a way that the resulting datatype restriction matches the definition of IRI? Has anyone implemented a strictly correct IRI datatype in a Java datatype library (for Jing and MSV)? -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: If you want Fat Pings just use Atom!
On Aug 23, 2005, at 07:27, A. Pagaltzis wrote: I still dislike the idea of a “virtual closing tag” – it ain’t 1995 anymore, after all. You seem to be thinking that an XML parser needs to consider the whole document before reporting data to the app. This is not the case. If you have a document that lacks the end tag, the fatal error is hit when the data stream ends. All the subtrees rooted at children of the document element will be just fine. Try it with any streaming SAX parser. In this case, the data stream ends only if either party decides to close the connection. The parser will never know how long the document would have been. From the parsers point of view it looks like a broken stream while reading a finite doc. There's nothing in the XML spec requiring the app to throw away the data structures it has already built when the parser reports the error. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: spec bug: can we fix for draft-11?
On Aug 4, 2005, at 21:55, Joe Gregorio wrote: Some sections of this specification are illustrated with fragments of a non-normative RELAX NG Compact schema [RELAX-NG]. However, the text of this specification provides the definition of conformance. A complete schema appears in Appendix B. This is quoted directly from Section 1.3. This whitespace issue is a good illustration of why the schema isn't normative ;) This thread makes me wonder if taking the schema seriously enough to actually encourage validation against the schema causes more harm than good. Perhaps I should remove the Atom schema from the presets of http://hsivonen.iki.fi/validator/ . I would vote for leaving the text as is and having the validator give errors on whitespace. ITYM, the Feed Validator and not a RELAX NG validator. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: Notes on the latest draft.
On Jul 20, 2005, at 08:08, James Cerra wrote: HTML has many entities predefined. If you use HTML content, are those entities allowed (after being escaped, of course)? That would make it really really hard to normalize to text or XML without doctype processing. No. You are supposed to use a tag soup parser for HTML. Tag soup parsers don't process the DTD. They have a hard-coded table of character entities. Also, how does Atom interact with HTML 5, You put the stuff in there and in time clients will adapt? I still say that version or doctype attributes should be allowed to solve disambiguities and allow compatibility with future versions of those specs. I am strongly against catering for doctype sniffing on the XHTML side. Public/System identifiers can still be used to identify type without validating it No, they cannot. See http://hsivonen.iki.fi/doctype/#xml -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: RNG validators capable of fully using the Atom schema?
On Jul 12, 2005, at 19:16, Norman Walsh wrote: I use Kohsuke's MSV. (msv.dev.java.net) Cool. Thanks. I had allowed relaxng.org tell me that MSV Supports XML syntax only. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
RNG validators capable of fully using the Atom schema?
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. (Specifically, I would like to fully support the Atom schema in http://hsivonen.iki.fi/validator/ ) -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: atom:type, xsl:output
On May 28, 2005, at 05:28, James Cerra wrote: Henri Sivonen, Yes, but MSIE^H^H^H^Hsome xml processors (cough cough) still inappropriately use comments for that purpose. I am not familiar with that. What purpose exactly? Why should Atom support it? MSIE conditional comments. See other person's reply. I thought they were for text/html tag soup only. Anyway, I think Atom should not try to enable such bogosity in XML. And yes: I know that Atom is not FTP or HTTP. I'm looking at the Atom entry uploader's POV rather than the downloader's perspective. The Atom API is a way to simplify managing web sites: Is it really? Straight bytes over HTTP PUT seems a lot simpler to me than Base64 in an XML envelope over HTTP PUT. Vanilla XML processors don't act on PIs. They report them to the application--in this case the Atom processor. So Atom Processors MUST be between any XML and PI processor stages? That sucks! It means just to display Atom, I can't use a generic XSLT processor like Saxon or MSIE. What PIs do they act on besides the style sheet PI, which must appear in the prolog (so conforming tools should not act on it if it appears within atom:content)? Depending on an entity reference and not being able to accept the straight replacement text is just wrong. I agree. I'm just bringing up possible incompatibilities for debate! I don't think that's an incompatibility that deserves catering for. That's a non-issue. You don't just throw away the DOCTYPE but parse the original document with it and reserialize as a DOCTYPEless fragment. You don't lose well-formedness or content. You only lose the shallow attribute data typing provided by the DTD. Well, that data could be valuable. IDness is. For practical purposes, the other stuff is not. There are other solutions for IDness. With DOCTYPE information associated with embedded content, it becomes possible to transform entries into valid XML or HTML documents. What do you need valid documents for if the validity is just an property internal to the document? That is, the document is valid according to its own rules as opposed to conforming to the rules required by some downstream software. Some apps change their behavior with well-formed and valid modes. That seems like a bad idea. Can you give examples? DOCTYPE switching may be evil, but it is currently a necessary evil. It is not a necessary evil for XML. I am strongly against any Atom feature motivated by or designed for enabling and/or encouraging doctype sniffing in XML. Please see http://hsivonen.iki.fi/doctype/#xml I see this as low risk (it doesn't break anything and could even be an OPTIONAL feature) Optional features always have a cost. Also, they tend to become de facto mandatory for everyone or de facto useless for everyone. Atom's main purpose is to facilitate software to software communication. When interop or implementation ease and readability conflict, readability should yield. That's why I proposed they should be externally referenced (or base64ed), so the Atom processor doesn't touch them! This is a hint to authors on how to avoid a common error. Base64 XML in XML was rejected earlier in the working group process. There is nothing intrinsically bad about DOCTYPE sections Yes, there is. On the Web you cannot trust that the recipient is using an XML processor that processes the DOCTYPE beyond checking the internal subset for well-formedness. An optional feature that does not degrade gracefully when not supported is bad. DOCTYPE is such a feature. In the cases where the DOCTYPE can be gracefully ignored, the DOCTYPE is pointless. No, any well formed XML processor MUST expand internal entities and add replaced attributes as well. This is NOT OPTIONAL. So is expat non-conforming? Atom is not claiming that you could embed the literal source of any XML doc. You can embed the stuff that canonicalization would preserve. Yet you can do that with PNG, PDF, or other content via base 64 encodings. It is silly to allow that for them and not XML. Looks like straight HTTP without an Atom envelope in between suits your needs better. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: atom, xslt processors (Re: atom:type, xsl:output)
On May 28, 2005, at 04:54, James Cerra wrote: Aristotle, Henri Sivonen, Yes, but any Atom document MUST be processable from just an XML processor, an ?xml-stylesheet? processor, A conforming xml-stylesheet processor will only act on the PI if it appears in the prolog. For this reason, it would be possible to allow xml-stylesheet PIs in atom:content and spec that they are part of the content document, so that an XML document with the PI in its prolog could be constructed from the content. (2) RSS and Atom documents are now processed with ?xml-stylesheet? PIs, and there is no way to formally specify when those instructions should be executed (except for specific instances that don't matter here). Perhaps it follows that you should not use xml-stylesheet if you don't want it to be acted upon. So any ?xml-stylesheet? nodes, and PI nodes in general, must be assumed to be linked to the document as a whole; Only if the PI appears in the prolog. That's one reason the following is not true: Vanilla XML processors don't act on PIs. They report them to the application--in this case the Atom processor. Instead, they could be reported to the PI processor before the atom processor. Why do you think it is appropriate to have a random PI processor in between the XML processor and the Atom processor? -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: Review of Atom 0.8 Spec against W3C QA Specification Guidelines
On May 24, 2005, at 20:54, Karl Dubost wrote: A feed validator doesn't have to use a schema, but it could use it for a non-normative check (you may have problems - or even kicking in more lengthy checking code only when the schema is violated). This is up to the validator authors. Validation is something very precise. It can be validated against a DTD, or against a Schema or another grammar language, etc. At least the Feed validator could become a Feed checker which develops a heuristic to check if the requirements of the specification are verified. :))) up to the validator authors :) The Feed Validator has always been a Feed Checker technically. I complained about the naming terminology when the Feed Validator came out. I don't expect the name to change now. Even with validators that perform a precise check using a schema, it is important to know what kind of check the validator performs. In the case of Atom, the schema that ships with the specification is a RELAX NG Compact Syntax schema with embedded Schematron. When used with a RELAX NG validator that does not support embedded Schematron (eg. http://hsivonen.iki.fi/validator/), the validator will precisely ignore the embedded Schematron. A hand-crafted checker can potentially be more useful than a validator that is limited to what is checkable using a given schema language. Case point: DTDs and attribute data types. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: Review of Atom 0.8 Spec against W3C QA Specification Guidelines
On May 24, 2005, at 23:44, Paul Hoffman wrote: So why are we discussing where the Atom format document doesn't match up to W3C test specification guidelines? Atom has been advertised as thoroughly specified before it is even known what exactly the upcoming RFC will specify. Assessing the level of thoroughness using an outside metric makes sense to me. Whether the WG wants to act on the assessment is another matter. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: atom:type, xsl:output
On May 25, 2005, at 06:46, James Cerra wrote: fter being processed by a XML processor, any entites should be dereferenced to their text values and placed into the document tree. So this: atom:content type=application/xml lt;?xml version=1.0? lt;tag //atom:content would become the text string: atom:content type=application/xml xml version=1.0? tag //atom:content No. It becomes a tree: Element atom:content having attribute type=application/xml | \ Text: xml version=1.0? tag / (Newlines omitted.) -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: atom:type, xsl:output
On May 25, 2005, at 06:43, James Cerra wrote: If the intended Atom content contains essential comments, There should be no such thing as essential comments. The XML spec does not require XML processors to report comments to the app. Hence, comments are inappropriate for transferring essential data. processing instructions, These could be supported in embedded content if the Atom spec said PIs in atom:content belong in content and should not be acted upon by the Atom processor. entities Entities can be flattened. DOCTYPE declaration(s) If DOCTYPE is essential for the receiving app, you've got bigger problems than Atom. Hardwiring IDness based on namespaces is more practical than relying on DTD-based data typing. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: some small comments on 08
On May 23, 2005, at 12:31, Julian Reschke wrote: For the record: I am +1 on http://www.intertwingly.net/wiki/pie/PaceOptionalXhtmlDiv. +1 from me too. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: Change Control (was: extensions -- Atom NS and unprefixed attributes)
On May 17, 2005, at 17:47, Antone Roundy wrote: What possible advantage would there be to allowing just anyone to add elements to Atom's namespace, or any other namespace, for that matter? I can't think of any. If you add to an existing namespace, you don't need to add confusing namespace declarations. In my opinion, alteration of a namespace by anyone other than the entity that created it, or someone authorized by its creator, would completely violate the nature of namespaces. Sure. But it happens for practical reasons. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: PaceOtherVocabularies
On May 17, 2005, at 01:35, Robert Sayre wrote: Markup from other vocabularies (foreign markup) can be used in an Atom document, but MUST be namespace-qualified and in a namespace other than Atom's. Surely attributes on extension elements don't need to be ns-qualified? -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: Atom 1.0?
Marketing: Atom I'm looking forward to an article by Mark Pilgrim about the incompatible versions of Atom deceitfully marketed as one thing. :-) (Which is why I said +1 to Atom 1.0.) -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: Atom 1.0?
On May 10, 2005, at 05:29, Tim Bray wrote: Atom 1.0 +1 for Atom 1.0 in order to distinguish from 0.3. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: Last Call: 'The Atom Syndication Format' to Proposed Standard
On May 8, 2005, at 06:30, Walter Underwood wrote: White space is not particularly meaningful in some of these languages, so we cannot expect them to suddenly pay attention to that just so they can use Atom. Why not? We expect them not no insert other random characters there. What do the same producers do with XHTML? Opera 7.53 and Safari 1.3 render a space between the second and third Kanji in http://hsivonen.iki.fi/test/cjk-whitespace.xhtml There will be plenty of content from other formats with this linguistically meaningless white space. Why not just get rid of it in the producer end like you have to get rid of form feeds? -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: the atom:copyright element
On May 8, 2005, at 19:45, Eric Scheid wrote: On 9/5/05 12:18 AM, Graham [EMAIL PROTECTED] wrote: What other rights can be associated with content? Habeas Corpus? The right to bear arms? trademarks? If your lawyer tells you that you need to recite some legalese about trademarks, wouldn't (s)he tell you to put the legalese where people will see it with the trademarks--ie. in the content? moral rights (not just attribution)? Can you give an example of a jurisdiction where it is useful to declare moral rights in a way other than indicating the author? Do you have a jurisdiction in mind where the moral rights can be vested in an entity other than the author who is a natural person? -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: Atom feed refresh rates
On May 5, 2005, at 16:24, Walter Underwood wrote: --On May 5, 2005 8:07:15 AM -0500 Mark Pilgrim [EMAIL PROTECTED] wrote: Not to be flippant, but we have one that's widely available. It's called the Expires header. You need the information outside of HTTP. To quote from the RSS spec for ttl: This makes it possible for RSS sources to be managed by a file-sharing network such as Gnutella. Caching information is about knowing when your client cache is stale, regardless of how you got the feed. Virtually everyone with IP connectivity can do HTTP, and HTTP has the Expires header. If this feature is important to you, why would you switch to a transfer protocol that doesn't have the feature? (I am not claiming anything about the actual Gnutella features.) To me, the what if the feed is not over HTTP argumentation seems theoretical over-generalization. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: Autodiscovery
On May 4, 2005, at 02:56, David Nesting wrote: Plus, feed is kind of application-specific. What about related? It's a spec for discovering *feeds*. It is proper to have an app-specific rel value to avoid feed-specific apps downloading non-feed related documents. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: Last Call: 'The Atom Syndication Format' to Proposed Standard
On Apr 29, 2005, at 12:17, Martin Duerst wrote: Making this more precise is definitely desirable. But there is also an i18n issue: This works fine for languages that use spaces between words. It doesn't work for languages that don't have spaces between words (Chinese, Japanese, Thai,...). If Text elements are only used for short things such as names or titles, that's not a big issue, the text in question can just be put on a single line. However, when the texts in question are long, it's a serious issue, and should be fixed. You seem to be assuming that the length of a line is restricted in XML source. Why? As far as I can tell, it should be permissible to produce Atom documents that contain no LF or CR characters. Can't languages without spaces use long source lines and apply soft wrapping in a source view if necessary? Why is this a wire format problem? -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: xml:base and html rendering
On Apr 21, 2005, at 15:26, Robert Sayre wrote: No. xml:base doesn't mean anything in (x)html, ever, so there is no need for a structural measure. In practice, anything that end up in the xml: namespace is part of the infrastructure and generic underpinnings won't turn them off based on higher-level specs. Are you suggesting Mozilla is wrong in supporting xml:base in a generic way (including in XHTML)? -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: Standalone schema?
On Apr 20, 2005, at 01:29, Robert Sayre wrote: Henri Sivonen wrote: Is the Relax NG schema from the appendix hosted as a standalone HTTP resource somewhere on atompub.org ? Now it is. http://atompub.org/2005/04/18/atom.rnc Thanks. Could you also set the MIME type to application/vnd.relax-ng.rnc instead of text/plain? -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: PaceXmlContentWrapper
On Apr 20, 2005, at 05:21, Graham wrote: iii) Require that xhtml and *xml content elements have only a single child node. That is, all xml must be wrapped in an enclosing element (eg contenttext bbold/b more text/content would be invalid). -1. The Atom content element is the wrapper. If your rendering mechanism requires a single root but not atom:content, shouldn't it be your responsibility to add it? -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: PaceXmlContentWrapper
On Apr 20, 2005, at 11:53, Bill de hÓra wrote: Henri Sivonen wrote: On Apr 20, 2005, at 05:21, Graham wrote: iii) Require that xhtml and *xml content elements have only a single child node. That is, all xml must be wrapped in an enclosing element (eg contenttext bbold/b more text/content would be invalid). -1. The Atom content element is the wrapper. If your rendering mechanism requires a single root but not atom:content, shouldn't it be your responsibility to add it? Not if the content formats have single roots by design. Yes, */xml and */*+xml obviously require a single root. However, type='xhtml' is a fragment--not a full XHTML doc. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: Standalone schema?
On Apr 20, 2005, at 17:52, Robert Sayre wrote: Henri Sivonen wrote: Could you also set the MIME type to application/vnd.relax-ng.rnc instead of text/plain? Hmm. That's not a registered type, is it? It doesn't appear in the registry. I thought that type had consensus on the OASIS Relax NG mailing list in last July, but apparently the registration has not been carried out. I guess that leaves application/octet-stream, then. :-/ (It seems to me the MIME type system is dysfunctional and extension/foo, where foo is the commonly used filename extension would go a long way for new types.) -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Standalone schema?
Is the Relax NG schema from the appendix hosted as a standalone HTTP resource somewhere on atompub.org ? -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments
On Apr 14, 2005, at 22:07, Robert Sayre wrote: Bill de hÓra wrote: If there is not a tidy way out of this, or we don't just agree to scope it as a point solution for a particular flavour of XHTML, I suggest we revisit the xhtml:div approach altogether. Bill, I don't think the problem is exclusive to the outer div. I can't find any version of XHTML that allows xh:p/ where xh is bound to the XHTML namespace URI. DTDs and namespaces are inherently incompatible. I think the restrictions the official DTDs place on namespace declarations should be ignored when embedding XHTML in Atom. (Note that the XHTML Modularization DTDs have stuff that can be parametrized.) -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments
On Apr 14, 2005, at 10:07, Thomas Broyer wrote: [1] http://www.w3.org/TR/xhtml1-schema/ For the record, James Clark has made Relax NG schemas for some flavors of XHTML 1.x. Surely James Clark is at least as good an authority as the W3C. :-) http://www.thaiopensource.com/relaxng/xhtml/ -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments
On Apr 13, 2005, at 01:02, Robert Sayre wrote: How about this text for XHTML: If the value of type is xhtml, the content of the Text construct MUST be a single XHTML div element [XHTML transitional reference], and SHOULD be suitable for handling as XHTML. Instead of saying XHTML it would be clearer to say XHTML 1.x or defining it in terms of the XHTML 1.x namespace URI. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments
On Apr 13, 2005, at 03:18, Asbjørn Ulsberg wrote: namely to use a Strict DOCTYPE. type='xhtml' takes a fragment and Atom is DTDless. Better to stay away from the word DOCTYPE. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments
On Apr 13, 2005, at 15:37, A. Pagaltzis wrote: * Henri Sivonen [EMAIL PROTECTED] [2005-04-13 08:25]: On Apr 13, 2005, at 01:02, Robert Sayre wrote: [XHTML transitional reference] Instead of saying XHTML it would be clearer to say XHTML 1.x or defining it in terms of the XHTML 1.x namespace URI. He already did, no? Not as clearly as possible. If 1.x is meant, it should be clearly pointed out. If 1.0 (not Ruby nor the What WG stuff) is meant, it should be clearly pointed out. I prefer 1.x over 1.0 or 2.0. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments
On Apr 14, 2005, at 00:10, Graham wrote: On 13 Apr 2005, at 8:31 pm, David Powell wrote: I agree that the Atom RFC shouldn't be a moving target. How about if we: Make an IANA registry of Atom Text Types, requiring some level of RFC to create new ones. Put text, html, and xhtml in the registry, and specify that xhtml means XHTML1.0 Describe what processors should do if they encounter an Atom Text Type that they don't understand. -1 -1 from me as well. Overkill. I think it will be safe to leave any further formats to a new rev of the spec, since whatever new thing needs to be added would have to have reached similar popularity to either plain text or HTML. That pretty much rules out XHTML 2.0, doesn't it? Good ideas from the XHTML 2.0 namespace are being backported to the XHTML 1.x namespace, so it is unlikely for XHTML 2.0 to reach large-scale popularity. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments
On Apr 11, 2005, at 22:23, Norman Walsh wrote: But I hope not. I don't really want to have to rev the Atom format spec when XHTML 2.0 comes out. With care, I want to just put XHTML 2.0 stuff in my xhtml:div elements and let the down-stream appliation work it out. It will be nice to have the div in the XHTML 1.x namespace and the contents in the XHTML 2.0 namespace. Namespace div indeed. :-) But XHTML 2.0 is a different language form XHTML 1.x. Why do you think XHTML 2.0 fragments should be allowed as type='xhtml'? Just because XHTML 2.0 has XHTML in the name? If it is not about the name, why not DocBook NG fragments? One might argue that DocBook NG has a better chance of getting browser support than XHTML 2.0. ;-) -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: copyright
On Mar 25, 2005, at 14:41, Henry Story wrote: Clearly it would be very helpful if there were a machine readable way to set copyright policy on entries. Any thoughts on that? Legalese is complicated enough that it cannot be fully expressed in machine readable form unless the machine is AI-complete. CC has created an RDF vocabulary for describing their license elements. However, when you start describing eg. the GFDL with CC's vocabulary, you are on shaky ground, because the license details may not be exactly equivalent to the CC terms. It seems to me that it is more straight-forward to identify a known license than to try to describe a license. Tantek Çelik has publicized and mozilla.org (among others) has adopted a 'license' rel value for HTML link. This approach avoids the issue of machine-readable licenses and software interpreting legalese, because a human programmer needs to supply the software with known license URIs. Obviously, this doesn't work nicely with obscure licenses but assumes that the license URIs are well-known. The solution is also less crufty than hiding RDF in discardable comments. (Hiding copyright metadata in discardable comments is a bad idea, because in some jurisdictions there may soon be legislation that makes it illegal to discard copyright metadata. The XML spec says software may discard comments.) However, you cannot make everyone who provides useful feeds to describe their policy, so someone running a feed aggregation service still needs all lawyer who can convincingly argue against the permission culture. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: copyright, Creative Commons, and DRM in Atom/RSS
On Mar 25, 2005, at 18:38, Bob Wyman wrote: http://bobwyman.pubsub.com/main/2005/03/lazyweb_query_a.html The basic message is that we should not be writing anything that implies that Creative Commons should be used for Digital Rights Management. +1 BTW, I think the anti-DRM clause of CC is really intended as an anti-anti-circumvention clause and should be rephrased as such. See http://lists.debian.org/debian-legal/2005/03/msg00423.html -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: Attributes on the xhtml:div wrapper
On Mar 17, 2005, at 00:57, David Powell wrote: c) disallow XHTML attributes on the xhtml:div wrapper, but allow xml:lang. If you allow declaring the language, why do you disallow declaring the dominant writing direction (dir)? Shouldn't they be allowed or disallowed together? d) Get rid of the wrapper div. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: On PaceXhtmlNamespaceDiv
On Feb 17, 2005, at 15:09, Bill de hÓra wrote: 1. About Rob's example from MT; the point is twofold a) that what the tool provides ootb Wasn't that what type='HTML' was for? -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: On PaceXhtmlNamespaceDiv
On Feb 16, 2005, at 10:53, Robert Sayre wrote: This is how I generate my Atom 0.3 feed, using the popular Movable Type program: content type=text/html mode=escaped xml:lang=en xml:base=$MTBlogURL encode_xml=1$ $MTEntryBody encode_xml=1$ /content How's that relevant wrt. type='XHTML'? If you doubt the robustness of concatenation with XHTML, why wouldn't you keep using entity-encoded HTML? (FWIW, I don't believe the pace removes the telescoping divs issue. I predict the div as part of the envelope is unintuitive to the ViewSourceClan, who will assume everything in the Atom namespace is part of the envelope and everything in the XHTML namespace is part of the payload.) -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: On PaceXhtmlNamespaceDiv
On Feb 17, 2005, at 00:18, Robert Sayre wrote: However, this is not going to reflect what's in MySQL. Does it need to? Could anybody except for you check? Should anybody (including you) care? Is it part of conformance? Yes. No. Yes. Yes. Why does the feed have to reflect what is in MySQL? What if you had Markdown content (or similar non-(X)HTML) in MySQL? -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: PaceXhtmlNamespaceDiv
On Feb 10, 2005, at 18:02, Sam Ruby wrote: We have seen on this very mailing list people who have an above average understanding of XML trip over this particular area numerous times. Those trip-ups have not been as much about div vs. no div but about XMLNS which we can't and should not attempt to change. I should also note that typed examples on the list and output from debugged serializers are different things.* * Aka. the tools will save us argument. Despite the tools will save us argument being unpopular, I think it is unwise for an average developer to approach XMLNS without proper tools. -- Henri Sivonen [EMAIL PROTECTED] http://iki.fi/hsivonen/
Re: type=HTML
On Feb 9, 2005, at 20:06, Julian Reschke wrote: I'll agree that it's easier to produce for those who don't understand XML. But shouldn't we recommend XHTML for those who *do* understand XML/XHTML (and actually read the spec)? Don't you expect those people to use XHTML without being told so just out of an aesthetic dislike of entity-encoded HTML? -- Henri Sivonen [EMAIL PROTECTED] http://iki.fi/hsivonen/
Re: type=HTML
On Feb 10, 2005, at 01:00, Graham wrote: Does type=XHTML have *any* strengths compared to type=HTML (expect being easier to produce if you don't have HTML in the first place?). * Mixing MathML for future Gecko-based aggregators * Mixing SVG for aggregators that use a future version of Gecko/WebCore/Presto * Less repulsive for people who really don't like entity-encoded HTML * Easier to produce with some tools (even if you have HTML in the first place) -- Henri Sivonen [EMAIL PROTECTED] http://iki.fi/hsivonen/
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: 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: 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/
PaceXhtmlNamespaceDiv
On Feb 7, 2005, at 19:50, Paul Hoffman wrote: Even if you sent in a +1, 0, or -1 previously on a particular Pace, send it in again. Hopefully, add a short or long comment on why you feel it should or should not be considered part of the Atom core. -1 on PaceXhtmlNamespaceDiv The div is an additional container inside the Text construct container. The main purpose of the div is to save one for loop in a document-tree/pull-based client or, alternatively, to give a false sense of correctness in tag soup concatenation-based clients. IMO, neither rationale warrants a meaningless element inside a Text construct. (Noting that the Pace was retracted by the original author.) -- Henri Sivonen [EMAIL PROTECTED] http://iki.fi/hsivonen/
Re: PaceXhtmlNamespaceDiv
On Feb 7, 2005, at 21:52, Antone Roundy wrote: +1, but I wouldn't object to a variant that required either the DIV with a namespace declaration OR for the namespace to be declared in content or before content. Examples of what I'd think was acceptable: feed ... xmlns:xhtml=... / ... contentThis is xhtml:bbold/xhtml:b/content This is against the Pace. Are you really supporting the pace? OR content xmlns:xhtml=... /This is xhtml:bbold/xhtml:b/content This is against the Pace, too. OR contentdiv xmlns=... /This is bbold/b/content This one is against the pace as well. Also, the 'b' element would be in the same namespace as 'content', which seems wrong. Here's what I think is just plain ugly and shouldn't be allowed: contentThis is b xmlns=... bold/b/content IMO, that should be allowed. Atom has no business in restricting the syntactic sugar provided by Namespaces in XML. OR contentThis is xhtml:b xmlns:xhtml=... bold/xhtml:b/content IMO, this on should be allowed on the same grounds. -- Henri Sivonen [EMAIL PROTECTED] http://iki.fi/hsivonen/
Re: PaceArchiveDocument
On Feb 7, 2005, at 20:04, Robert Sayre wrote: 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. -1 to the Pace. Me three. -- Henri Sivonen [EMAIL PROTECTED] http://iki.fi/hsivonen/
Re: PaceXhtmlNamespaceDiv
For the record, the additional loop that the div would save in a
DOM-based client is not that hard:
copyLangAndBase(atomTextCostruct, targetDivInTemplate);
for (Node n = atomTextCostruct.getFirstChild(); n != null; n =
n.getNextSibling()) {
targetDivInTemplate.appendChild(templateXhtmlDocument.importNode(n,
true));
}
Is that too much to ask from clients?
--
Henri Sivonen
[EMAIL PROTECTED]
http://iki.fi/hsivonen/
Re: PaceXhtmlNamespaceDiv
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 a:feed xmlns:a='http://purl.org/atom/ns#draft-ietf-atompub-format-04' version='draft-ietf-atompub-format-04 : do not deploy' xmlns:h='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 h:a href='http://dvforge.com/themousebt.shtml'The Mouse BT/h:a from some outfit ... OR feed xmlns='http://purl.org/atom/ns#draft-ietf-atompub-format-04' version='draft-ietf-atompub-format-04 : do not deploy' xmlns:h='http://www.w3.org/1999/xhtml' xml:lang='en-us' ... entry ... content type='XHTML'I was in the drugstore picking up a prescription and wandered into the computer section, where I found myself impulse-buying h:a href='http://dvforge.com/themousebt.shtml'The Mouse BT/h:a from some outfit ... -- Henri Sivonen [EMAIL PROTECTED] http://iki.fi/hsivonen/
Re: RELAX NG Grammar question
On Feb 4, 2005, at 01:02, Norman Walsh wrote: | As for the XHTML thing, I think this is going to happen all the time (foreign | markup in embedded XHTML) and I don't think we should try to get in the way. | However, I just now tried to think of some spec language to express this and | came up empty. -Tim I think the spec language is fine If the value of type is XHTML, the content of the Text construct MAY contain child elements. The content SHOULD be XHTML text and markup that could validly appear directly within an xhtml:div element. Depending on what W3C DTD you choose to read, you could put MathML or even SVG there, which is fine, IMO, because I don't think it makes sense to exclude well-known vocabularies that you could legitimately serve embedded in application/xhtml+xml. -- Henri Sivonen [EMAIL PROTECTED] http://iki.fi/hsivonen/
Re: Posted PaceTextRules
On Feb 1, 2005, at 11:08, Martin Duerst wrote: +1 with the minor nit that lone line breaks should be considered spaces--not disregarded. Thus: Software displaying this text SHOULD remove white-space at the beginning and end; and treat sequences of one or more XML white-space characters as a single space. Except that that's completely inadequate for some Asian languages (Chinese, Japanese, Thai,...). Point to a spec developed by experts if you need to rather than trying to reinvent the wheel. I used http://www.w3.org/TR/2004/REC-xml-20040204/#AVNormalize and the default white-space behavior of browsers as the precedent. Could you please point to a spec that is developed by experts and does not reinvent the wheel? Also, I would appreciate a pointer to a document explaining the issues with Chinese, Japanese and Thai. I don't think what I wrote above in any way precludes soft line breaks for display at places that do not have adjacent XML white-space. (All this would be so much easier if XML used linefeeds and tabs for pretty-printing and those could always be dropped and spaces were always meaningful content. Too late to change it though.) -- Henri Sivonen [EMAIL PROTECTED] http://iki.fi/hsivonen/
Re: Issues with draft-ietf-atompub-format-04
On Jan 31, 2005, at 03:11, Asbjørn Ulsberg wrote: On Sun, 30 Jan 2005 22:06:23 +0200, Henri Sivonen [EMAIL PROTECTED] wrote: So how many European sites besides the EU have the resources to provide translations of the *same* content in multiple languages at the same time? The company I work in (the Norwegian Broadcasting Company), for instance. And most definately the BBC. And many other broadcasters, including RN (Radio Netherlands) which broadcasts and publishes content in many different languages. Don't any Finish broadcasters publish or broadcast content in both Finish and Sami for instance? There are TV programs in Swedish, but they are not translations of Finnish content. Both the Finnish and Swedish branches have news, but they have separate editorial processes. I expect the Sami radio to have separate editorial staff as well so that their content is not a mere translation of the content any Finnish-language channel. How many of those can't provide multiple feed links and really want to stuff everything in a single feed? All of the above, I'd presume. If it can be stuffed into the same feed, everyone would of course rather do that than create separate documents for each language. Why? The feed takes longer to download that way and you pay more for bandwidth. Aren't language alternatives within a feed over-engineering. No, not at all. It makes it possible to do for those who want, but don't have any implications on other producers. All features involve a cost at the consumer side. -- Henri Sivonen [EMAIL PROTECTED] http://iki.fi/hsivonen/
Re: Posted PaceTextRules
On Jan 31, 2005, at 03:00, Graham wrote: Software displaying this text SHOULD remove white-space at the beginning and end; collapse white-space between words; and disregard line break, tab and other formatting characters. in 3.1.1 (TEXT). +1 with the minor nit that lone line breaks should be considered spaces--not disregarded. Thus: Software displaying this text SHOULD remove white-space at the beginning and end; and treat sequences of one or more XML white-space characters as a single space. -- Henri Sivonen [EMAIL PROTECTED] http://iki.fi/hsivonen/
Re: Comments on draft 05, was: I-D ACTION:draft-ietf-atompub-form at-05.txt
On Jan 31, 2005, at 01:32, Sam Ruby wrote: Julian Reschke wrote: atomTitle type=XHTML xmlns:xhtml=http://www.w3.org/1999/xhtml; Less: xhtml:em lt; /xhtml:em /atomTitle (hope I got these right). This is not only right, but also a good example of why many people would prefer to have another element so that they don't have to deal with prefixes: Their serializer should deal with them. If they are concatenating source strings, using XHTML is risky. atomTitle type=XHTML div xmlns=http://www.w3.org/1999/xhtml;Less: em lt; /em/div /atomTitle The above is similar to your example, but not _identical_ to your example, given the current spec. You could also have atom:title type=XHTML xmlns=http://www.w3.org/1999/xhtml; Less: em lt; /em /atom:title (assuming the atom prefix to be bound higher up) -- Henri Sivonen [EMAIL PROTECTED] http://iki.fi/hsivonen/
Re: Comments on draft 05, was: I-D ACTION:draft-ietf-atompub-form at-05.txt
On Jan 31, 2005, at 16:05, Julian Reschke wrote: Can't we just get rid of the defaulting? That would make the spec simpler with little additional verbosity in the instance documents. If there is no default, someone will still omit the attribute and consumers will try to cope. I think it is better if they cope in the same way normatively. -- Henri Sivonen [EMAIL PROTECTED] http://iki.fi/hsivonen/
Re: Issues with draft-ietf-atompub-format-04
On Jan 30, 2005, at 19:06, Anne van Kesteren wrote: In Europe there are lots of different languages. It does not make sense to provide a feed based on language negotiation since feed aggregators do not support that. So how many European sites besides the EU have the resources to provide translations of the *same* content in multiple languages at the same time? How many of those can't provide multiple feed links and really want to stuff everything in a single feed? Aren't language alternatives within a feed over-engineering. -- Henri Sivonen [EMAIL PROTECTED] http://iki.fi/hsivonen/
Re: PaceXhtmlNamespaceDiv posted
On Jan 30, 2005, at 21:06, Julian Reschke wrote: OK, I'll try to rephrase: changing the protocol format because one implementor says that this makes it easier to implement IMHO is a bad idea. Of course things look differently if this issue affects more platforms/parsers/toolkits. FWIW, one could let WebCore see the Atom Text construct element without harm. So if a single container is needed, the Text construct itself is the obvious container. -- Henri Sivonen [EMAIL PROTECTED] http://iki.fi/hsivonen/
Re: PaceXhtmlNamespaceDiv posted
On Jan 29, 2005, at 00:39, Sam Ruby wrote: Henri Sivonen wrote: On Jan 28, 2005, at 20:21, Sam Ruby wrote: I also don't like the restriction on where namespace declarations must be placed, but overall, I believe that the pace is a good idea. I, for one, use gnu.xml.pipeline.NSFilter for ensuring the namespace correctness in my RSS feed. If the current spec language stands, I will be able to trivially add Atom output with type='XHTML' by doing a DOM to DOM copy (without div cruft) and letting the serialization phase sort out the namespace declarations for me. If this pace was accepted, I'd have to break the namespace abstraction and fiddle with the namespace declaration details to meet additional requirements that are unnecessary as per Namespaces in XML. Are you saying that you can do a DOM to DOM copy to place a series of elements inside the following: atom:feed/atom:entry/atom:content But you would find it extraordinarily difficult to place the exact same series of elements inside the following: atom:feed/atom:entry/atom:content/xhtml:div If so, I would find such an assertion to be hard to accept. No, of course those two are equally easy. The latter is just crufty. My point was that having the namespace declarations appear in a particular choice of syntactic sugar would hinder the use of an automatic namespace declaration manager. If element names are prefixed, string concatenation is not an option anyway. Which is why it would be harmful to imply that a string concatenation implementation was ok. If element names are not prefixed (as is the case with the overwheming majority of existing HTML), adding a div is exactly what makes things safe for simple string concatenators. I don't see how it makes string concatenation easier that concatenating the contents of the Text construct otherwise. But since it doesn't work in all cases, it certainly should not be specced for. Speccing for tag soup concatenation would just encourage implementors to do tag soup concatenation. Wasn't the whole reason for the existence of type='XHTML' to provide something that is more sound from the XML point of view than entity-encoded HTML? And no, a div does not give any useful hint to the ViewSourceClan, because it is an anything goes element. I am sorry I brought up the subject of Text constructs. How about withdrawing both PaceTypeTextRedundant and PaceXhtmlNamespaceDiv and sticking to what draft-ietf-atompub-format-04 said? -- Henri Sivonen [EMAIL PROTECTED] http://iki.fi/hsivonen/
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: 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: 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: 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: 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/
Difference of TEXT and XHTML?
Quoting from draft-ietf-atompub-format-04: 3.1.1 type Attribute ... If the value is TEXT, the content of the Text construct MUST NOT contain child elements. Such text is intended to be presented to humans in a readable fashion. Thus, software MAY display it using normal text rendering techniques such as proportional fonts, white-space collapsing, and justification. ... If the value of type is XHTML, the content of the Text construct MAY contain child elements. The content SHOULD be XHTML text and markup that could validly appear directly within an xhtml:div element. Receiving software which displays the content MAY use the markup to aid in displaying it. Considering that TEXT MAY be white-space collapsed (why not SHOULD?) and XHTML allows anything that could go in div including text, isn't TEXT redundant? What's the difference between: atom:title type='TEXT'I do not like ![CDATA[]]marqueegt;/atom:title and atom:title type='XHTML'I do not like ![CDATA[]]marqueegt;/atom:title ? Shouldn't both render as I do not like marquee? FWIW, with the exception of content, I think allowing only %inline XHTML elements would make more sense than allowing %flow. -- Henri Sivonen [EMAIL PROTECTED] http://iki.fi/hsivonen/
Re: Difference of TEXT and XHTML?
On Jan 26, 2005, at 23:18, Tim Bray wrote: On Jan 26, 2005, at 12:44 PM, Henri Sivonen wrote: What's the difference between: atom:title type='TEXT'I do not like ![CDATA[]]marqueegt;/atom:title and atom:title type='XHTML'I do not like ![CDATA[]]marqueegt;/atom:title ? Shouldn't both render as I do not like marquee? Yeah, but if you wanted to have 'not' in bold: title type='TEXT'I do not like lt;marquee/title (can't do it) title type='HTML'I do lt;bnotlt;/b like amp;lt;marquee/title title type='XHTML'I do bnot/b like lt;marquee/title But if you can always substitute type='TEXT' with type='XHTML' but not the other way round, what's the point of having type='TEXT' in the spec? -- Henri Sivonen [EMAIL PROTECTED] http://iki.fi/hsivonen/
Re: Difference of TEXT and XHTML?
On Jan 27, 2005, at 00:45, Robert Sayre wrote: But guess what, TEXT is *never* coming out of the spec, because it will eventually become impossible to write something that looks like markup if we don't have it. How so? What does type='TEXT' make possible to write that type='XHTML' with a single text node does not make possible to write? -- Henri Sivonen [EMAIL PROTECTED] http://iki.fi/hsivonen/
