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
Sunday, April 17, 2005, 9:47:39 AM, Henri Sivonen wrote: 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. I strongly agree. Namespaces are a pretty fragile technology; any solution that requires micro-management of namespace declarations is going to be even more fragile. As far as I know, XSLT and many XML APIs don't have any control over the position of namespace declarations. We shouldn't be forcing publishers to use printf to generate Atom. -- Dave
Using namespaces instead of 'type' (was: Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments)
On Thu, 14 Apr 2005 23:58:05 +0200, Antone Roundy [EMAIL PROTECTED]
wrote:
atom:content type=XHTML xmlns:atom=our namespace URI xmlns=XHTML's
namespace URI
divThis is XHTML content,br /
and the default namespace is XHTML's./div
/atom:content
This example made me think about another solution for the Content
Constructs of Atom. Today, they all reside in the Atom namespace, which of
course, makes most sense. But even though I see it is a major hack, won't
putting Content Constructs inside the target namespace of the embedded
content be a solution to tell what type of content we are embedding
without having to use a 'type' element? Example:
feed xmlns=atom ns
...
content xmlns=http://www.w3.org/1999/xhtml;
h1Booyah! This is an XHTML fragment./h1
/content
/feed
Since Atom consumers need to have special handling for each 'type'
('html', 'xhtml', 'text') we provide today, we might as well imho signify
this with the XHTML namespace as with a 'type' attribute. The problem is
that it's difficult to say «this is to be parsed as escaped SGML» in
contrary to «this is to be read as plain text». Alas, we need a solution
for non-XML types in Atom if we think using namespaces is a good enough
solution for XML types.
If we take the hack even further, we could create pseudo namespaces for
text and HTML types as well. Or perhaps even a general SGML namespace. So
when we want to embed text in Content Constructs, we do it like this:
content xmlns=atom ns#text
*Booyah! This is an text fragment.*
/content
And when we want to embed HTML, we do it like this:
content xmlns=atom ns#html
lt;h1gt;Booyah! This is an text fragment.lt;/h1gt;
/content
I've already mentioned that I think this solution is a hack, and I'm not
sure I like it, but what I do like about it is that it gives us a general
way to deal with XML content that is much simpler (imho at least) than any
other previous solution (which have included 'type', 'mode' and various
other attributes).
Yes, there is no element called 'xhtml:content' in the XHTML
specification, but we won't have _valid_ (although wellformed) XHTML in
Atom anyways, so why strive so hard to reach something we won't reach
anyway? The XHTML content in Atom will be valid XML. It can't ever be
valid XHTML. Let's just settle with that and move forward, no?
--
Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/
«He's a loathsome offensive brute, yet I can't look away»
RE: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments
Bill, Thank you for the answer. I'm being cautious here, because vocabulary integration is one of my main concerns in the direction Atom is taking, and I hate to see everything hard-coded with special deference to particular HTML tags. If we can't solve the problems without recourse to spec changes, we won't be building an extensible standard. Could you let me know why RNG can't be normative? Is it written down somewhere in the RFC? There's normative BNF in various IETF RFCs and I don't see much difference, especially since RNC looks like BNF and it's now an ISO standard. I do tend to disagree on the terminology issue, still, though. I think that saying we have an XML-in-XML problem leads people to think of encapsulation and semantic-blind content carrying (think base64 or CDATA), whereas calling it mixed vocabulary implies solutions that are at the semantic level, and I believe lead to extensibility. Dave Orchard and Dare Obasanjo have written eloquently on designing languages for for integration and extensibility [1] [2] [3]. The articles point out some obstacles in using XML Schema so I suggested RNG; although prose would work, it's more, well, wordy, and open to interpretation in the implementation. Leigh. [1] http://www.xml.com/pub/a/2003/12/03/versioning. [2] http://www.xml.com/pub/a/2004/07/21/design.html [3] htmlhttp://www.pacificspirit.com/blog/2004/07/27/dare%20versioning%20extensibility%20article%20comparison -Original Message- From: Bill de hÓra [mailto:[EMAIL PROTECTED] Sent: Thursday, April 14, 2005 4:35 PM To: Klotz, Leigh Cc: atom-syntax@imc.org Subject: Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments Klotz, Leigh wrote: I think that casting this problem as XML-in-XML is a problem in itself, It's a problem, but I don't see as casting. But like I said, if that's not the technical problem, I'll gladly shut up. If it is, we could do worse than be cognizant as to what we're working around. and I believe that a more productive approach is to consider it a mixed-namespace document with extensibility as in CDF, and use RNG for the formal description. Except that strictly speaking the rng is informative and won't count formally (altho' it's a nice approach). We'd have to spec it as text. cheers Bill
Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments
Klotz, Leigh wrote: I'm being cautious here, because vocabulary integration is one of my main concerns in the direction Atom is taking, and I hate to see everything hard-coded with special deference to particular HTML tags. If we can't solve the problems without recourse to spec changes, we won't be building an extensible standard. Atom's content element allows arbitrary XML. Atom's Text construct does not. If the format were to allow basically anything in those, there wouldn't be much of a standard. Could you let me know why RNG can't be normative? Is it written down somewhere in the RFC? There's normative BNF in various IETF RFCs and I don't see much difference, especially since RNC looks like BNF and it's now an ISO standard. There's no procedural reason, it was a working group decision. Robert Sayre
Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments
* A. Pagaltzis [EMAIL PROTECTED] [2005-04-15 20:20]: * Antone Roundy [EMAIL PROTECTED] [2005-04-15 00:10]: feed xmlns=our namespace URI ... atom:content type=XHTML xmlns:atom=our namespace URI xmlns=XHTML's namespace URI divThis is XHTML content,br / and the default namespace is XHTML's./div /atom:content I like this. A lot. One better, with my @type='xml' suggestion instead of @type='xhtml': feed xmlns=atom-ns-uri xmlns:atom=atom-ns-uri !-- ... -- atom:content type=xml xmlns=http://www.w3.org/1999/xhtml; pThis is XHTML content./p pThe default namespace is XHTML's./p /atom:content !-- ... -- /feed That gets rid of the need to declare the atom: prefix over and over. Regards, -- Aristotle
Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments
On Friday, April 15, 2005, at 02:30 PM, A. Pagaltzis wrote: * A. Pagaltzis [EMAIL PROTECTED] [2005-04-15 20:20]: * Antone Roundy [EMAIL PROTECTED] [2005-04-15 00:10]: feed xmlns=our namespace URI ... atom:content type=XHTML xmlns:atom=our namespace URI xmlns=XHTML's namespace URI divThis is XHTML content,br / and the default namespace is XHTML's./div /atom:content I like this. A lot. One better, with my @type='xml' suggestion instead of @type='xhtml': feed xmlns=atom-ns-uri xmlns:atom=atom-ns-uri !-- ... -- atom:content type=xml xmlns=http://www.w3.org/1999/xhtml; pThis is XHTML content./p pThe default namespace is XHTML's./p /atom:content !-- ... -- /feed That gets rid of the need to declare the atom: prefix over and over. While this approach has it's appeal, I'm pretty sure I'm in favor of keeping xhtml as a special case for a few reasons: 1) I presume (when you presume you make a pres of you and me?) that XHTML is going to be by far the most common XML type used in atom:content, and least for a while. 2) It makes it more difficult to determine the type of data. We know it's XML, but to find out whether it's a flavor of XML that we know how to deal with, we have to discover the namespace of the content. That will sometimes be easy to determine, as in the example above, because the namespace is declared on the content element. However, sometimes, it may be done like this: feed xmlns=atom-ns-uri xmlns:xhtml=xhtml-ns-uri !-- ... -- content type=xml xhtml:pThis is XHTML content./xhtml:p xhtml:pThe default namespace is XHTML's./xhtml:p /content !-- ... -- /feed In this case, we'd have to find a child element and check it's namespace. We've already discussed and rejected the idea of requiring namespaces to be declared at a particular point in Atom documents, so I think requiring to be declared in atom:content to make the type discovery easy has already been rejected. The alternative would be to use the full MIME type instead of just xml and use that instead of the namespace to discover the type. But there's still a problem... 3) Some people are still going to do it the way it's being done now, leaving us with the ambiguous status of the div. Is it part of the content or just a container? Antone
Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments
On Friday, April 15, 2005, at 03:51 PM, A. Pagaltzis wrote: * Antone Roundy [EMAIL PROTECTED] [2005-04-15 23:05]: 2) It makes it more difficult to determine the type of data. We know it's XML, but to find out whether it's a flavor of XML that we know how to deal with, we have to discover the namespace of the content. ... Including the full MIME type is cruft, IMHO, in that it duplicates information that is already there. Not for non-XML data types, which don't have namespaces. How about saying that the namespace associated with a particular prefix on the atom:content element level is to be consulted for the type of the content? In the simpler case, this could be supplied as an extra attribute, say @ns. ...which duplicates information that's already there. The only ones who need to be particularly careful then are those who create new feeds from existing feeds: they need to be careful to assign appropriate values for @ns attributes rather than just copying them thru blindly. This is not difficult; the necessary tools exist in XSLT/XPath, f.ex. ...which not everyone is going to be using. Copying and pasting @type will be easy for everyone. 3) Some people are still going to do it the way it's being done now, leaving us with the ambiguous status of the div. Is it part of the content or just a container? Is that really a great concern? Both semantically and presentionally, xhtml:div is neutral, so considering it to be part of the content does not change its interpretation. Thus, I dont see any harm in eliding the issue altogether. This question has been discussed before, and the group is divided on it. Actually, it's not presentationally neutral. Consider the difference between these: a href=http://www.example.com/;This is the entry title/a This is the entry content. a href=http://www.example.com/;This is the entry title/a divThis is the entry content./div In the first, the content is displayed inline, and thus the line doesn't break after the link. In the second, there's a linebreak. See also http://www.imc.org/atom-syntax/mail-archive/msg13535.html
Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments
Klotz, Leigh wrote: Bill, Thank you for the answer. I'm being cautious here, because vocabulary integration is one of my main concerns in the direction Atom is taking, and I hate to see everything hard-coded with special deference to particular HTML tags. If we can't solve the problems without recourse to spec changes, we won't be building an extensible standard. Could you let me know why RNG can't be normative? Is it written down somewhere in the RFC? It is written down. There is consensus in the WG that the spec text be the final word. There's normative BNF in various IETF RFCs and I don't see much difference, especially since RNC looks like BNF and it's now an ISO standard. I do tend to disagree on the terminology issue, still, though. I think that saying we have an XML-in-XML problem leads people to think of encapsulation and semantic-blind content carrying (think base64 or CDATA), whereas calling it mixed vocabulary implies solutions that are at the semantic level, and I believe lead to extensibility. Extensibility so far in Atom has been firstly along the axis of particular attributes/values that applies to the format itself. Second is along the axis of adding names from other namespaces as children of the entry element making Atom a general purpose metadata container (the entry then is much like a dictionary). But while XHTML and text is an issue atm, it's worth pointing out that atom:content can carry arbitrary XML. [After some thought, I'll stand by the XML in XML thing while believing it open up a level of debate that is maybe not helpful right now.] Dave Orchard and Dare Obasanjo have written eloquently on designing languages for for integration and extensibility [1] [2] [3]. The articles point out some obstacles in using XML Schema so I suggested RNG; although prose would work, it's more, well, wordy, and open to interpretation in the implementation. They have.The problem for us going that route is as I see it that we'll risk imposing processing constraints and coordination on producers and consumers that will be rejected in practice. [My personal view is that this speaks to modularity and not extensibility; for example things like RDF, or say Lisp, have a very notion of what an extension is. Being able to mix and match lexically and between versions is not what I think about first when it comes to extension, but I've been told that's not a common interpretation.] cheers Bill
Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments
Robert Sayre wrote: [snip: an example with mixed XHTML and MicroSoft stuff] Thank you, Asbjørn: this is a delightful little problem. You see, XHTML validity is specified in terms of DTDs. Near as I can tell, that example and some of the XHTML examples in the spec are 'invalid' because the local names don't match the DTD, and there are stray xmlns declarations. If any of the current versions of XHTML allow that, we should probably point to that one, but I don't know if any of them do. Well, I think an XML Schema defined XHTML [1] would allow xmlns declarations but if you want to include foreign elements and attributes in XHTML, it'll never be valid, except if you write your own XHTML Module and/or hybrid document type (like the XHTML+MathML+SVG Profile [2]). However, Atom requires wellformedness, not validity. So your wording, Rob, seems good to me (even if I still disagree with the div wrapper...): 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. The reference should IMHO point to both XHTML 1.0 (allows the lang and name attributes) and XHTML 1.1 (allows ruby), i.e. having two XHTML references. The day XHTML will have an RNG modularized schema (seems to be the case for XHTML 2.0, but we need XHTML 1.x), Atom would be able to precisely define (still informative as the Atom RNC schema is not normative) the content model of the Text Constructs, e.g. extending XHTML with xsd:any and xsd:anyAttribute (I don't know how to say that in RelaxNG). [1] http://www.w3.org/TR/xhtml1-schema/ [2] http://www.w3.org/TR/XHTMLplusMathMLplusSVG -- Thomas Broyer
Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments
Anne van Kesteren wrote: Norman Walsh wrote: | XHTML 2 does have a different namespace. Ouch. I had forgotten or failed to notice that. Yeah, using namespaces for versioning sucks... I don't have any. I'll tailor my content to suit what the major vendors support, just like I do with my plain old HTML today. In practice, my feeds contain no markup at all (because I'm still generating RSS and I will not produce escaped markup). I don't really like this point of view. This is exactly what creates interoperability problems and people will blame Atom in the end for promising to solve problems it does not. I don't think is comes under the category of namespaces for versioning problem. We made this problem ourselves, due to the consensus view that says default namespaces are so valuable we have the bake an inverted dependency into Atom, ie the feature of having to have Atom know about XHTML to treat it special is arguably a design problem. And our answer to the consequences of the self-made design problem is to design a registry? I don't see that as a simplifying move. 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. cheers Bill
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 Thursday, April 14, 2005, at 06:04 AM, Bill de hÓra wrote: I don't think is comes under the category of namespaces for versioning problem. We made this problem ourselves, due to the consensus view that says default namespaces are so valuable we have the bake an inverted dependency into Atom, ie the feature of having to have Atom know about XHTML to treat it special is arguably a design problem. Looking at a Blogger-generated Atom 0.3 feed: content type=application/xhtml+xml xml:base=http://antone.geckotribe.com/bustedworld/; xml:space=preserve div xmlns=http://www.w3.org/1999/xhtml;The package for my son's diapers says 22-37 lbs, but there is iabsolutely no way/i they could hold that much stuff without leaking!/div /content ...so we certainly didn't create the problem by requiring the div--xmlns attributes were being added to divs in Atom feeds before we came up with the idea. What we've discovered is that there is no way to make the XHTML namespace the default namespace while having the content be a valid XHTML fragment. We'd have to allow the html element inside of atom:content to do that. Other options include not worrying about whether the content is valid XHTML (though of course it must be well-formed XML), or only requiring that the content of the div be a valid XHTML fragment, and not the div itself, which, since the div isn't part of the content, wouldn't be entirely strange.
Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments
Henri Sivonen wrote:
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/
So Atom could propose a Relax NG schema that could validate the included
XHTML as well!
And as the Atom Relax NG schema is not normative and the text would say
the content SHOULD be valid XHTML, if one want to use invalid XHTML,
his feed is still valid Atom.
If I understand RNG and RNC correctly, the schema would say something like:
include http://www.thaiopensource.com/relaxng/xhtml/modules/text.rng {
Inline.class |= element * - atom:* - xhtml:*
Block.class |= element * - atom:* - xhtml:*
Core.attrib = attribute * - atom:* - xhtml:* { text }*
}
# Include here every other needed XHTML schema
# should be all except struct.rng and frames.rng, and evenly legacy.rng
# define the xhtmlDiv used by Text Constructs and atom:content
# it might be needed to redefine allowed attributes
xhtmlDiv = xhtml:div
# if we want to get rid of the div wrapper, use sth like that instead:
# xhtmlDiv = div.attlist, Flow.model
--
Thomas Broyer
Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments
Bill de hra 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. Robert Sayre
Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments
Robert Sayre wrote: I can't find any version of XHTML that allows xh:p/ where xh is bound to the XHTML namespace URI. !DOCTYPE xh:div PUBLIC -//W3C//DTD XHTML 1.1//EN [ !ENTITY % NS.prefixed INCLUDE !ENTITY % XHTML.prefix xh ] xh:div xmlns:xh=http://www.w3.org/1999/xhtml; xml:lang=en This does not a strictly conforming XHTML 1.1 document as defined in xh:a href=http://www.w3.org/TR/xhtml11/conformance.html#strict; XHTML 1.1, section 2.1.1. Strictly Conforming Documents/xh:a but it xh:strongis/xh:strong a valid XML document, using the XHTML 1.1 DTD. /xh:div ...and this is the case only when validating against a DTD. Validating against the XML Schema [1] will allow any kind of prefix to be bound to the XHTML namespace: x:div xmlns=http://www.w3.org/1999/xhtml; xml:lang=en xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://www.w3.org/1999/xhtml http://www.w3.org/2002/08/xhtml/xhtml1-strict.xsd; This document is valid against the x:a title=W3C Note: XHTML 1.0 in XML Schema href=http://www.w3.org/TR/xhtml1-schema;XHTML 1.0 XML Schema/x:a, without any trickery. /x:div I believe the same thing happens (no needed trickery) when using a Relax NG schema, like the ones by James Clark. [1] http://www.w3.org/TR/xhtml1-schema/ -- Thomas Broyer
Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments
Klotz, Leigh wrote: I think that casting this problem as XML-in-XML is a problem in itself, It's a problem, but I don't see as casting. But like I said, if that's not the technical problem, I'll gladly shut up. If it is, we could do worse than be cognizant as to what we're working around. and I believe that a more productive approach is to consider it a mixed-namespace document with extensibility as in CDF, and use RNG for the formal description. Except that strictly speaking the rng is informative and won't count formally (altho' it's a nice approach). We'd have to spec it as text. cheers Bill
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
* Asbjrn Ulsberg [EMAIL PROTECTED] [2005-04-13 02:35]: Or, we should restrict the allowed XHTML versions in the specification to just include 1.x. That leads to different problems, though, since people would then think they could use XHTML 1.0 Frameset or XHTML 1.1, which are totally different from one another, and will hurt interoperability a great deal. Multiple proposals already posted for the wording of this section suggestion a refererence to the XHTML 1.0 Transitional spec. That would seem to have preempted this problem. Regards, -- Aristotle
Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments
--On April 13, 2005 9:06:59 AM +0300 Henri Sivonen [EMAIL PROTECTED] wrote: 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. This could work. XHTML 1.0 will not be confused with a media type. When XHTML 2.0 is ready, we can add a supplemental RFC which defines a new attribute value for that. wunder -- Walter Underwood Principal Architect, Verity
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
Norman Walsh wrote: / Anne van Kesteren [EMAIL PROTECTED] was heard to say: | 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. | | XHTML 2 does have a different namespace. Ouch. I had forgotten or failed to notice that. Yeah, using namespaces for versioning sucks... | Future versions of XHTML may | or may not have a DIV element. In theory, sure, but in practice? HTML isn't likely to lose the element with the local-name div is it, really? Ask Ian Hickson. I believe he is planning to drop it in the WHATWG version of XHTML. | Also, what do you expect feed readers to support for XHTML versions, etc. I don't have any. I'll tailor my content to suit what the major vendors support, just like I do with my plain old HTML today. In practice, my feeds contain no markup at all (because I'm still generating RSS and I will not produce escaped markup). I don't really like this point of view. This is exactly what creates interoperability problems and people will blame Atom in the end for promising to solve problems it does not. -- Anne van Kesteren http://annevankesteren.nl/
Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments
Anne van Kesteren wrote: I don't really like this point of view. This is exactly what creates interoperability problems and people will blame Atom in the end for promising to solve problems it does not. Atom promised to solve HTML interop issues? Robert Sayre
Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments
Wednesday, April 13, 2005, 7:06:09 PM, Anne van Kesteren wrote: | Also, what do you expect feed readers to support for XHTML versions, etc. I don't have any. I'll tailor my content to suit what the major vendors support, just like I do with my plain old HTML today. In practice, my feeds contain no markup at all (because I'm still generating RSS and I will not produce escaped markup). I don't really like this point of view. This is exactly what creates interoperability problems and people will blame Atom in the end for promising to solve problems it does not. 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. -- Dave
Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments
* David Powell [EMAIL PROTECTED] [2005-04-13 21:50]: 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. This is what I first thought, too. Obviously, the last point of these points would be the most important, and extra care would have to be taken not to foul it up. But is this really a good idea? One aspect I dont like about this proposal is that it swaps a fairly important part of Atom out of the core spec and into a registry, which makes it harder for first-time implementors to pull together all the pieces required. Another aspect is that it seems that it would hurt interop: even if I know which version of the Atom spec is used by an upstream producer or expected by a downstream consumer, I cant know whether we agree on text types. If support for a set of text types is inextricably tied to support for a certain version of the Atom spec, then no ambiguities arise. A final aspect is that because this is so central to Atom, I dont know if it can be guaranteed that updates to the spec will not require updates in the registry or vice versa. Should that ever happen, registrations will suddenly have to track which Atom spec version they are for, or contain multiple definitions to be chosen from according to Atom version, or some other mechanism, any form of which will tie registrations and core spec versions to each other. That negates any gain ever had by separating the text types out of the core spec. All in all, I think creating registries is best avoided. Regards, -- Aristotle
Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments
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 I think introducing new core data types negates the point of having core, well-known data types. XHTML 2.0 is an issue we can solve now. 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. Graham
Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments
On Wed, 13 Apr 2005 14:39:48 +0200, A. Pagaltzis [EMAIL PROTECTED] wrote: Multiple proposals already posted for the wording of this section suggestion a refererence to the XHTML 1.0 Transitional spec. That would seem to have preempted this problem. Do we really want to exclude XHTML 1.1 as allowed content in Atom documents? -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments
On Wed, 13 Apr 2005 08:08:42 +0200, Henri Sivonen [EMAIL PROTECTED] wrote: namely to use a Strict DOCTYPE. type='xhtml' takes a fragment and Atom is DTDless. Better to stay away from the word DOCTYPE. Of course. Still, the allowed elements and attribtues inside the div of Atom Content constructs is bound to the version of XHTML we choose. And the way to identify which version of XHTML you use happens to be done with a DOCTYPE and appurtenant DTD (and sadly not an XSD or similar), so I'm using it only as a way to identify which versions we are to use, not because I want the actual DOCTYPE construct to be allowed within an Atom document. And please note that I have not suggested any form of wording for this specification text yet, so this can be formulated however the group finds best. I have no proposals for specification text at the moment. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
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
Asbjørn Ulsberg wrote: On Wed, 13 Apr 2005 08:08:42 +0200, Henri Sivonen [EMAIL PROTECTED] wrote: namely to use a Strict DOCTYPE. type='xhtml' takes a fragment and Atom is DTDless. Better to stay away from the word DOCTYPE. Of course. Still, the allowed elements and attribtues inside the div of Atom Content constructs is bound to the version of XHTML we choose. Real world example: summary div xmlns=http://www.w3.org/1999/xhtml; xmlns:o=urn:schemas-microsoft-com:office:office Dell delivered my replacement 2405FPW today.span style= /spanThe white line pixel problem had actually disappeared on my first monitor when I switched it on the second day, but when a problem has shown itself once, who is to say it would not come back.span style= /spanI feel better knowing I have a new monitor with zero problems from the start.p class=MsoNormal !--[if !supportEmptyParas]-- !--[endif]--o:p/ /p p class=MsoNormalSo, now all the problems are over, how is the 2405FPW?span style= /spanOutstanding!!!br/ !--[if !supportEmptyParas]-- !--[endif]--br/ /div /summary What do we have to say about this? Robert Sayre
Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments
[[ wearing my IETF weenie hat, not my co-chair hat ]] At 10:10 PM +0100 4/13/05, Graham wrote: -1 I think introducing new core data types negates the point of having core, well-known data types. XHTML 2.0 is an issue we can solve now. 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. Fully agree with Graham. IANA registries are mostly for things that not core to actually running a spec, and the type of content seems quite core. The should this be relegated to an IANA registry or not question come up in almost every IETF WG because it is a question of what is and is not core for a developer. If a protocol has a reason to have lots of registries (such as IPsec, which has a dozen different types of transforms), then it is safer to put more core-ish things in a registry. But if it has only a few, then we should assume that most developers won't bother to look in the IANA registries, greatly reducing interoperability for things that appear only in a registry. I'm fairly certain the Atom format is in the second category. --Paul Hoffman, Director --Internet Mail Consortium
Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments
On Wed, 13 Apr 2005 23:42:29 +0200, Robert Sayre [EMAIL PROTECTED] wrote: Real world example: [snip example] What do we have to say about this? As far as I can see, the code is valid XHTML 1.0 Strict (and thus also both Transitional, Frameset and XHTML 1.1), so I'm not sure what point you're making, Robert. Sure, the code is far from pretty, but the validity of it is okay. We can't demand validation or validity in any way, but we can and should encourage people to follow W3C's recommendations. And for a long time, they have been to code against the strictest DTD possible for the version of (X)HTML you are using. Transitional is a DTD to code against if you're transitioning from invalid DOCTYPE-less HTML or HTML 3.2 to valid HTML 4.01 Strict. XHTML 1.0 Transitional is a mistake, but that discussion is off topic, so I'll leave that for now. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments
Asbjørn Ulsberg wrote: On Wed, 13 Apr 2005 23:42:29 +0200, Robert Sayre [EMAIL PROTECTED] wrote: Real world example: [snip example] What do we have to say about this? As far as I can see, the code is valid XHTML 1.0 Strict (and thus also both Transitional, Frameset and XHTML 1.1), so I'm not sure what point you're making, Robert. Sure, the code is far from pretty, but the validity of it is okay. Thank you, Asbjørn: this is a delightful little problem. You see, XHTML validity is specified in terms of DTDs. Near as I can tell, that example and some of the XHTML examples in the spec are 'invalid' because the local names don't match the DTD, and there are stray xmlns declarations. If any of the current versions of XHTML allow that, we should probably point to that one, but I don't know if any of them do. Here's an example of what I mean: http://validator.w3.org/check?uri=http%3A%2F%2Ffranklinmint.fm%2F2005%2F04%2F13%2Fhmm.html What in the hay are we supposed to reference? Robert Sayre
Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments
On Thu, 14 Apr 2005 05:37:42 +0200, Robert Sayre [EMAIL PROTECTED] wrote: Thank you, Asbjørn: this is a delightful little problem. You see, XHTML validity is specified in terms of DTDs. Near as I can tell, that example and some of the XHTML examples in the spec are 'invalid' because the local names don't match the DTD, and there are stray xmlns declarations. If any of the current versions of XHTML allow that, we should probably point to that one, but I don't know if any of them do. Ah, nice catch. Didn't even think about it, but you're right: Well-formed XML is not necessarily valid XHTML. What in the hay are we supposed to reference? That's a very good question I really wished I had an answer to. But right now, I don't. :-\ -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
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: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments
On Apr 11, 2005, at 1:18 PM, Norman Walsh wrote: Sigh. I'm not sure what to do now. I think it would be nice if Atom 1.0 could work with XHTML 1.0 and 2.0. But that means tinkering a bit with the language. We need to do a bit of cleanup. But bear in mind that the measuring stick is interoperability. In the case of type=html, the language is well-taken (from 3.1.1.1): If the value of type is html, the content of the Text construct MUST NOT contain child elements, and SHOULD be suitable for handling as HTML suitable for handling as HTML may be a bit hand-wavy but corresponds exactly to reality and is about as far as we can realistically go. For XHTML on the other hand: If the value of type is xhtml, the content of the Text construct MUST be a single XHTML div element [W3C.REC-xhtml-basic-20001219]. The XHTML div MUST contain XHTML text and markup that could validly appear within an XHTML div element. First, the word validly has to go. There is little (any?) interoperability benefit, but immense costs, in requiring XHTML validation. I suggest rewording to make this congruent with the HTML language If the value of type is xhtml. the content of the Text construct MUST be a single XHTML div element. The XHTML div must contain XHTML 1.0 [XHTML traditional reference] text and markup that SHOULD be suitable for handling as XHTML 1.0 Traditional. I recommend we use Transitional, since I don't think we should get into micro-managing the purity of the payload; but clearly Frameset would be going too far. -Tim
Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments
Tim Bray wrote: We need to do a bit of cleanup. But bear in mind that the measuring stick is interoperability. In the case of type=html, the language is well-taken (from 3.1.1.1): If the value of type is html, the content of the Text construct MUST NOT contain child elements, and SHOULD be suitable for handling as HTML suitable for handling as HTML may be a bit hand-wavy but corresponds exactly to reality and is about as far as we can realistically go. 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. Robert Sayre
Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments
On Apr 12, 2005, at 3:02 PM, 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. +1 --Tim
Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments
On Wed, 13 Apr 2005 00:02:48 +0200, Robert Sayre [EMAIL PROTECTED] 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. Good, but I would like us to have the same recommendations in the Atom specification as W3C, namely to use a Strict DOCTYPE. How to word this is still a bit blurred to me. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments
On Tue, 12 Apr 2005 19:45:56 +0200, Henri Sivonen [EMAIL PROTECTED] wrote: 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? Yes. If it is not about the name, why not DocBook NG fragments? Because DocBook does not have XHTML in its name, and will not under any circumstance cause confusion with Atom using the term XHTML as a type for content. Since XHTML 1.0 and 2.0 and most likely 2.1, 3.0 and whatnot will bear the names XHTML, we should allow all of them to be used in Atom. Or, we should restrict the allowed XHTML versions in the specification to just include 1.x. That leads to different problems, though, since people would then think they could use XHTML 1.0 Frameset or XHTML 1.1, which are totally different from one another, and will hurt interoperability a great deal. I'd say that we should limit the allowed XHTML versions (including both version number and DOCTYPEs) to be used in Atom to XHTML 1.0 Transitional, XHTML 1.0 Strict and XHTML 1.1. Since XHTML 2.0 isn't finished yet, it is a bit problematic including language about it in the Atom specification, so I think we should leave it out at least until it is done. Then we can patch Atom somehow with an I-D or whatever to include language about XHTML 2.0. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments
On Apr 11, 2005 3:23 PM, Norman Walsh [EMAIL PROTECTED] wrote: I don't really want to have to rev the Atom format spec when XHTML 2.0 comes out. +1 -joe -- Joe Gregoriohttp://bitworking.org
Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments
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. XHTML 2 does have a different namespace. Future versions of XHTML may or may not have a DIV element. I agree that this might be out the scope of Atom, but it does create problems for interoparability. Also, what do you expect feed readers to support for XHTML versions, etc. -- Anne van Kesteren http://annevankesteren.nl/
Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments
On Sat, Apr 09, 2005 at 08:28:40PM +0900, Martin Duerst wrote: 2) Section 4.1.3.3 Item 2 The text: for example, br as lt;br. Is this right? Should it be: for example, br as lt;brgt;. We don't need to escape the in text content, as far as I can tell. Correct. From http://www.w3.org/TR/REC-xml/#syntax: The right angle bracket () MAY be represented using the string gt;, and MUST, for compatibility, be escaped using either gt; or a character reference when it appears in the string ]] in content, when that string is not marking the end of a CDATA section. Are you suggesting to escape it anyway for consistency/readability? Wouldn't be more readable, in my eyes. OTOH since someone has asked the question who presumably is fairly knowledgable about XML, and most people people are not, would it be worth putting a brief comment pointing to the appropriate section of the XML TR? Note that in XML the right angle bracket () need not be entity escaped in many common situations. See REF. Or something like that. James -- /--\ James Aylett xapian.org [EMAIL PROTECTED] uncertaintydivision.org
Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments
On Apr 10, 2005, at 2:30 AM, James Aylett wrote:
OTOH since someone has asked the question who presumably is fairly
knowledgable about XML, and most people people are not, would it be
worth putting a brief comment pointing to the appropriate section of
the XML TR?
Note that in XML the right angle bracket () need not be entity
escaped in many common situations. See REF.
I think this is really extraneous to our spec. I tend to agree with
Martin that is more legible than gt;, but many software packages
will always output gt; because of the small but nonzero possibility of
something like this happening:
if (a[b[i]]0) { c++; } // yer not well-formed
-Tim
Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments
At 17:34 05/04/09, Julian Reschke wrote: Quoting from Andrew Newton's questions relayed by Scott: http://www.imc.org/atom-syntax/mail-archive/msg14048.html From: Andrew Newton [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 05, 2005 6:25 PM To: Scott Hollenbeck Cc: [EMAIL PROTECTED] Subject: Re: [xml-dir] FW: draft-ietf-atompub-format-07.txt is ready for IETF last call ... 2) Section 4.1.3.3 Item 2 The text: for example, br as lt;br. Is this right? Should it be: for example, br as lt;brgt;. We don't need to escape the in text content, as far as I can tell. Correct. From http://www.w3.org/TR/REC-xml/#syntax: The right angle bracket () MAY be represented using the string gt;, and MUST, for compatibility, be escaped using either gt; or a character reference when it appears in the string ]] in content, when that string is not marking the end of a CDATA section. I'm slightly surprised to get such a comment from the XML Directorate. But I guess their main job isn't to check lowly syntax details. Are you suggesting to escape it anyway for consistency/readability? Wouldn't be more readable, in my eyes. I'd like to remind us of another related issue raised a few days ago (http://www.imc.org/atom-syntax/mail-archive/msg14045.html). XHTML content is currently restricted to XHTML Basic (see http://atompub.org/2005/04/04/draft-ietf-atompub-format-07.html#rfc.section.4.1.3.3, http://www.w3.org/TR/xhtml-basic/). As far as I can tell, this means *no styling*: - http://www.w3.org/TR/xhtml-basic/#s1.3.1: style attribute not supported (but class is), but I'd propose to go back to XHTML 1.0 Strict instead. Very good point. A very strong +1. Regards,Martin.
