Re: [Standards] Full XML
On Fri, Oct 10, 2008 at 12:42 AM, Brett Zamir <[EMAIL PROTECTED]> wrote: > If this could be allowed (at least the processing instructions), I would > think that XMPP could be used as the mechanism for accessing (or otherwise > transferring) a complete XHTML/SVG/MathML/etc. website (not only in the > context of messages, but also, e.g., as a Pubsub delivery; instead of typing > a URL, one could type a JID). (This should also make for an interesting > means of auto-updating webpage content incrementally as well, I think.) > > I am aware that XML can be delivered ala the bytestream specs, but I think > it could be more convenient to allow it in band and as XML. Full documents tend to be large (often several hundreds of KB) and my fear is that sending them in band would hinder much of the good "near real time" behavior of XMPP. Therefore it is not a problem of supported expressiveness that could be overcome someway, but of general stream behavior. Although if you find a way to send processing instructions, sooner or later you'll need a way for sending chunks of documents and this is easily done using bytestreams (also in band) bye -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: [EMAIL PROTECTED]
Re: [Standards] Full XML
Peter Saint-Andre wrote: Brett Zamir wrote: As comments, processing instructions, DTD subset, and entity reference are prohibited in XMPP, I was wondering whether there were or could be a standard way to escape at least processing instructions, comments, and the internal DTD subset (canonical features) so they could be reliably preserved? Why? Maybe you could tell us a bit more about your use cases. I had thought that such features could be preserved by making them the character data of particular elements in a special namespace (necessarily encapsulating such documents or fragments within a pseudo-root element in order to allow for document-root-level comments/processing instructions as well as Doctype declarations). I would think that providing some means for fidelity of an XML document transmitted over XMPP would be helpful (e.g., to share source code in band (without the need to escape), to allow full XHTML or SVG with 's to be shared, etc.). To do full XHTML, full SVG, or whatever, we would typically just include that data in a or stanza, properly namespaced of course. See for instance XEP-0071 (the XHTML-IM subset) and XEP-0072 (SOAP Over XMPP). But please note that XMPP is not designed for transferring complete XML documents as you seem to be envisioning. Yes. Is that not possible for any XMPP 2.0? :) Even if it is not so designed, an implementation (preferably in some agreed-upon standard way) could compensate for this: ..This could be converted back to a doctype. ..This should be converted back to a comment... ..This should be converted back to a processing instruction (like xml-stylesheet)... ..This should also be converted back to a comment... ... ... ..Might even send an external DTD's contents.. XML is such a ubiquitous standard, including with XHTML/SVG which use features like processing instructions, so I think it would be ideal to have some means of handling it (including the full-featured dialects) more thoroughly and with more fidelity. This wouldn't be all that hard to implement either, as an XSL stylesheet could do the trick to encode and add back the most important features (with doctype and entity references being likely (and unfortunate though less important) exceptions). If this could be allowed (at least the processing instructions), I would think that XMPP could be used as the mechanism for accessing (or otherwise transferring) a complete XHTML/SVG/MathML/etc. website (not only in the context of messages, but also, e.g., as a Pubsub delivery; instead of typing a URL, one could type a JID). (This should also make for an interesting means of auto-updating webpage content incrementally as well, I think.) I am aware that XML can be delivered ala the bytestream specs, but I think it could be more convenient to allow it in band and as XML. Brett
Re: [Standards] Full XML
On Wed, 08 Oct 2008 21:30:27 -0600 Peter Saint-Andre <[EMAIL PROTECTED]> wrote: > Brett Zamir wrote: > > As comments, processing instructions, DTD subset, and entity > > reference are prohibited in XMPP, I was wondering whether there > > were or could be a standard way to escape at least processing > > instructions, comments, and the internal DTD subset (canonical > > features) so they could be reliably preserved? > > Why? Maybe you could tell us a bit more about your use cases. > > > I had thought that such features could be preserved by making them > > the character data of particular elements in a special namespace > > (necessarily encapsulating such documents or fragments within a > > pseudo-root element in order to allow for document-root-level > > comments/processing instructions as well as Doctype declarations). I > > would think that providing some means for fidelity of an XML > > document transmitted over XMPP would be helpful (e.g., to share > > source code in band (without the need to escape), to allow full > > XHTML or SVG with 's to be shared, etc.). > > To do full XHTML, full SVG, or whatever, we would typically just > include that data in a or stanza, properly > namespaced of course. See for instance XEP-0071 (the XHTML-IM subset) > and XEP-0072 (SOAP Over XMPP). > > But please note that XMPP is not designed for transferring complete > XML documents as you seem to be envisioning. > Or they can be transfered just like any files or blocks of data. Pavel > > By the way, as far as section 12.1 in > > http://xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-07.html > > referring to entity references as being in section 4.2 of the XML > > standard, I think it perhaps should instead be section 4.1, where > > "entity reference" is defined. > > Thanks, I'll check that. > > Peter > -- Pavel Šimerda Freelancer v oblasti počítačových sítí, komunikace a bezpečnosti Web: http://www.pavlix.net/ Jabber & Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] Full XML
Brett Zamir wrote: > As comments, processing instructions, DTD subset, and entity reference > are prohibited in XMPP, I was wondering whether there were or could be a > standard way to escape at least processing instructions, comments, and > the internal DTD subset (canonical features) so they could be reliably > preserved? Why? Maybe you could tell us a bit more about your use cases. > I had thought that such features could be preserved by making them the > character data of particular elements in a special namespace > (necessarily encapsulating such documents or fragments within a > pseudo-root element in order to allow for document-root-level > comments/processing instructions as well as Doctype declarations). I > would think that providing some means for fidelity of an XML document > transmitted over XMPP would be helpful (e.g., to share source code in > band (without the need to escape), to allow full XHTML or SVG with > 's to be shared, etc.). To do full XHTML, full SVG, or whatever, we would typically just include that data in a or stanza, properly namespaced of course. See for instance XEP-0071 (the XHTML-IM subset) and XEP-0072 (SOAP Over XMPP). But please note that XMPP is not designed for transferring complete XML documents as you seem to be envisioning. > By the way, as far as section 12.1 in > http://xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-07.html > referring to entity references as being in section 4.2 of the XML > standard, I think it perhaps should instead be section 4.1, where > "entity reference" is defined. Thanks, I'll check that. Peter -- Peter Saint-Andre https://stpeter.im/
[Standards] Full XML
As comments, processing instructions, DTD subset, and entity reference are prohibited in XMPP, I was wondering whether there were or could be a standard way to escape at least processing instructions, comments, and the internal DTD subset (canonical features) so they could be reliably preserved? I had thought that such features could be preserved by making them the character data of particular elements in a special namespace (necessarily encapsulating such documents or fragments within a pseudo-root element in order to allow for document-root-level comments/processing instructions as well as Doctype declarations). I would think that providing some means for fidelity of an XML document transmitted over XMPP would be helpful (e.g., to share source code in band (without the need to escape), to allow full XHTML or SVG with 's to be shared, etc.). By the way, as far as section 12.1 in http://xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-07.html referring to entity references as being in section 4.2 of the XML standard, I think it perhaps should instead be section 4.1, where "entity reference" is defined. thank you, Brett
