📄 x455.htm
字号:
<HTML
><HEAD
><TITLE
>XML-Based</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.64
"><LINK
REL="HOME"
TITLE="Programming Jabber"
HREF="book1.htm"><LINK
REL="UP"
TITLE="Inside Jabber"
HREF="c445.htm"><LINK
REL="PREVIOUS"
TITLE="Inside Jabber"
HREF="c445.htm"><LINK
REL="NEXT"
TITLE="Asynchronous Nature"
HREF="x503.htm"></HEAD
><BODY
CLASS="SECT1"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>Programming Jabber</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="c445.htm"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
>Chapter 2. Inside Jabber</TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="x503.htm"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="JABTDG-CH-2-SECT-2.1"
>XML-Based</A
></H1
><P
>Arguments abound for and against XML in the arena of data representation.
XML is suited extremely well
to Jabber, which is suited extremely well to XML. This is for many reasons.</P
><P
>The alternatives for representing data in Jabber are: binary and ASCII text.
Binary? Well, perhaps binary data is more space efficient, but where is that
advantage
in the general scheme of things these days? Near the bottom of my list,
anyway, especially as it's always at the cost of readability.
ASCII? Well, yes, of course, ASCII is human readable, but because Jabber data
flow consists of a series of conversational chunks—independent
constructions in their own right—we need some sort of boundary mechanism
to separate these chunks. XML affords us a very nice way of packaging
individual chunks of data and giving their content meaning and context: These
individual chunks of information have structure too, and this structure
doesn't require any fixed-length madness either; XML allows the chunks, or
fragments, to bend and stretch as required, while still retaining their
meaning.</P
><P
>This flexibility also comes in the form of extensibility. It's straightforward
to add distinct "extensions" to a fragment in a way that does not compromise
the integrity of that fragment, and provides a structure to the extension
added. </P
><P
>So why reinvent the wheel when there are tools that can be taken off the
shelf to parse the data? There are many tried and tested XML libraries
out there, and to be able to receive (from the parser) the Jabber data in
a native format of your choice is a definite advantage. </P
><P
>Some of these arguments, concerning XML fragments and extensibility, will
become clearer in <A
HREF="c3612.htm"
>Chapter 5</A
>. Until then, consider
that Jabber makes good use of an XML feature called
<I
CLASS="EMPHASIS"
>namespaces</I
>.
<A
NAME="JABTDG-CH-2-FOOTNOTE-1"
HREF="#FTN.JABTDG-CH-2-FOOTNOTE-1"
>[1]</A
>
Namespaces are used in XML to segregate, or qualify, individual chunks of
data, giving tags a reference to which they belong. What the reference is,
in many ways is of secondary importance - the point is the delineation that
allows us
to manage content within an XML fragment that is logically divided into
sub-fragments. Consider <A
HREF="x455.htm#JABTDG-CH-2-EX-1"
>Example 2-1</A
>,
which shows a section of the imaginary
conversation from <A
HREF="c324.htm"
>Chapter 1</A
>.</P
><DIV
CLASS="EXAMPLE"
><A
NAME="JABTDG-CH-2-EX-1"
></A
><P
><B
>Example 2-1. Qualifying a fragment extension with a namespace</B
></P
><P
><PRE
CLASS="SCREEN"
><message type='chat' from='jim@company-a.com/home'
to='john@company-b.com/Desk'>
<thread>01</thread>
<body>Here's the link</body>
<x <TT
CLASS="USERINPUT"
><B
>xmlns='jabber:x:oob'</B
></TT
>>
<url>http://www.megacorp.co.uk/earnings3q.html</url>
<desc>Third Quarter Earnings for Megacorp</desc>
</x>
</message></PRE
></P
></DIV
><P
>The main part of the fragment is the
<TT
CLASS="LITERAL"
><message/></TT
> element
containing the <TT
CLASS="LITERAL"
><thread/></TT
> and
<TT
CLASS="LITERAL"
><body/></TT
> tags. The
<TT
CLASS="LITERAL"
><message/></TT
> element is the
"carrier" part of the fragment:</P
><P
><PRE
CLASS="SCREEN"
><message type='chat' from='jim@company-a.com/home'
to='john@company-b.com/Desk'>
<thread>01</thread>
<body>Here's the link</body>
</message></PRE
></P
><P
>But the fragment has been
embellished by an extension that is qualified by the
'<TT
CLASS="LITERAL"
>jabber:x:oob</TT
>' namespace:</P
><P
><PRE
CLASS="SCREEN"
><x xmlns='jabber:x:oob'>
<url>http://www.megacorp.co.uk/earnings3q.html</url>
<desc>Third Quarter Earnings for Megacorp</desc>
</x></PRE
></P
><P
>The <TT
CLASS="LITERAL"
>xmlns</TT
> attribute of the <TT
CLASS="LITERAL"
><x/></TT
>
tag declares that the tag, and any children of that tag, belong to, or are
qualified by, the <TT
CLASS="LITERAL"
>jabber:x:oob</TT
> namespace.
<A
NAME="AEN488"
HREF="#FTN.AEN488"
>[2]</A
>
This namespace
is different to the namespace that qualifies the carrier
<TT
CLASS="LITERAL"
><message/></TT
> tag, and the other elements
<TT
CLASS="LITERAL"
><presence/></TT
> and
<TT
CLASS="LITERAL"
><iq/></TT
> that appear at the same level.
The namespace that qualifies <I
CLASS="EMPHASIS"
>these</I
> tags is not
explicitly specified as an <TT
CLASS="LITERAL"
>xmlns</TT
> attribute; rather
it is declared when the XML stream is established. It is over this
XML stream that these elements flow. See <A
HREF="c3612.htm"
>Chapter 5</A
>
for more details on XML streams and namespaces.</P
><P
>The general point is that the <TT
CLASS="LITERAL"
>jabber:x:oob</TT
> qualified
extension is recognizable as an extension (by us, and more importantly, by
the XML parser) and can be dealt with appropriately—we are likely
to want to handle the information contained in the extension separately
from the rest of the message. </P
><P
>So Jabber uses the extensible XML format to contain and carry data between
endpoints.</P
><P
><I
CLASS="EMPHASIS"
>"XML between endpoints"?</I
> That sounds rather
generic to me—not something that's limited to providing an IM experience.
Indeed, that's the whole idea. </P
><P
>"XML Router" is a moniker often used to describe Jabber, by people who
have made this logical leap. Remove the IM mantle, and underneath we find
a system, an architecture, capable of being deployed to exchange and
distribute all manner of XML-encoded data.</P
></DIV
><H3
CLASS="FOOTNOTES"
>Notes</H3
><TABLE
BORDER="0"
CLASS="FOOTNOTES"
WIDTH="100%"
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="5%"
><A
NAME="FTN.JABTDG-CH-2-FOOTNOTE-1"
HREF="x455.htm#JABTDG-CH-2-FOOTNOTE-1"
>[1]</A
></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="95%"
><P
>http://www.w3.org/TR/REC-xml-names/</P
></TD
></TR
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="5%"
><A
NAME="FTN.AEN488"
HREF="x455.htm#AEN488"
>[2]</A
></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="95%"
><P
>This namespace is used in Jabber to carry information about "out of band"
(OOB) data; data that moves <I
CLASS="EMPHASIS"
>outside</I
> of the main
client-server-client pathways. When a client sends a file directly to
another client without sending that file via the server, this is said to
be "out of band".</P
></TD
></TR
></TABLE
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="c445.htm"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="book1.htm"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="x503.htm"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Inside Jabber</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="c445.htm"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Asynchronous Nature</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -