Re: [Standards] Questions about xhtml-im
Jehan wrote: Peter Saint-Andre;2169 Wrote: So I say that we update XEP-0071 to no longer disallow semantic markup (in fact there's no real way to do that in XHTML Modularization anyway!) and encourage experimentation to see which elements people really want to use (I think it will be mostly and , myself). /psa Yeah! That would be nice! :-) And yes I think also that the two emphasizing tags ( and ) are the two most useful tags above all others (or at least the most used)... OK I will update XEP-0071 along these lines soon. /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Questions about xhtml-im
Peter Saint-Andre;2169 Wrote: > Pavel Simerda wrote: > > On Sat, 02 Aug 2008 21:40:49 +0200 > > Maciek Niedzielski wrote: > > > >> Jehan wrote: > >>> But still for most end users, the best is wysiwyg > >> And this is why xhtml-im needs to be about formatting, not > semantics: > >> most end users want to get (and send) what they see. And they want > >> you to see what they see. > > > > I see no point in forbidding the semantics! > > > > I personally turn off xhtml-im as I have no way to just turn off > > styling (it's annoying to let others configure my fonts and colors, > > especially if it doesn't really work). If you don't forbid semantics, > I > > could turn off the styling and keep the seemantic part (styled to my > > own preferences). > > > > And... keeping the semantic markup doesn't do any harm to users that > > don't know about it. They'll just configure the fonts and colors, > that > > I don't care about (and I won't see). > > Right. I agree with both of you. :P > > So I say that we update XEP-0071 to no longer disallow semantic markup > > (in fact there's no real way to do that in XHTML Modularization > anyway!) > and encourage experimentation to see which elements people really want > > to use (I think it will be mostly and , myself). > > /psa Yeah! That would be nice! :-) And yes I think also that the two emphasizing tags ( and ) are the two most useful tags above all others (or at least the most used)... Jehan -- Jehan Jehan's Profile: http://www.jabberforum.org/member.php?userid=16911 View this thread: http://www.jabberforum.org/showthread.php?t=435
Re: [Standards] Questions about xhtml-im
Pavel Simerda wrote: On Sat, 02 Aug 2008 21:40:49 +0200 Maciek Niedzielski <[EMAIL PROTECTED]> wrote: Jehan wrote: But still for most end users, the best is wysiwyg And this is why xhtml-im needs to be about formatting, not semantics: most end users want to get (and send) what they see. And they want you to see what they see. I see no point in forbidding the semantics! I personally turn off xhtml-im as I have no way to just turn off styling (it's annoying to let others configure my fonts and colors, especially if it doesn't really work). If you don't forbid semantics, I could turn off the styling and keep the seemantic part (styled to my own preferences). And... keeping the semantic markup doesn't do any harm to users that don't know about it. They'll just configure the fonts and colors, that I don't care about (and I won't see). Right. I agree with both of you. :P So I say that we update XEP-0071 to no longer disallow semantic markup (in fact there's no real way to do that in XHTML Modularization anyway!) and encourage experimentation to see which elements people really want to use (I think it will be mostly and , myself). /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Questions about xhtml-im
On Sat, 02 Aug 2008 21:40:49 +0200 Maciek Niedzielski <[EMAIL PROTECTED]> wrote: > Jehan wrote: > > But still for most end users, the best is wysiwyg > > And this is why xhtml-im needs to be about formatting, not semantics: > most end users want to get (and send) what they see. And they want > you to see what they see. I see no point in forbidding the semantics! I personally turn off xhtml-im as I have no way to just turn off styling (it's annoying to let others configure my fonts and colors, especially if it doesn't really work). If you don't forbid semantics, I could turn off the styling and keep the seemantic part (styled to my own preferences). And... keeping the semantic markup doesn't do any harm to users that don't know about it. They'll just configure the fonts and colors, that I don't care about (and I won't see). Pavel -- Web: http://www.pavlix.net/ Jabber & Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] Questions about xhtml-im
Jehan wrote: But still for most end users, the best is wysiwyg And this is why xhtml-im needs to be about formatting, not semantics: most end users want to get (and send) what they see. And they want you to see what they see. -- Maciek xmpp:[EMAIL PROTECTED]
Re: [Standards] Questions about xhtml-im
On Fri, 1 Aug 2008 12:49:05 +0200 Jehan <[EMAIL PROTECTED]> wrote: > > Olivier Goffart;2116 Wrote: > > L > > It could also make use of a WIKI-like syntax > > > > Yes for my own, if really we are interested on client side text > structuration, the wiki style is one of the best approach for > technical users who don't like wysiwyg GUI, but still want to have > full control of their structure. For my own, I find it very boring > and slow to have to write xml tags or for emphasing, > whereas the wiki style is as powerful, but very fast to write (nearly > no difference with unformated writing, and especially no special > character like <, >, /, etc.), nice to read while still unsent, and > accurate. Writing ''emphasing'' is better than writing > emphasing!!! And lists with * or # are so "obvious", whereas > boring to write and it is easy to make a mistake of > unclosed tags. > > But still for most end users, the best is wysiwyg (they are not > willing to learn formatting rules, even as obvious as wiki ones), so > they don't care whether it is wiki or html "under" the skull. > Therefore I guess xhtml is a good choice for the finale formatting > inside the XMPP stream, because it is XML as XMPP, and wiki-style > could be used client-side as an implementation choice (which would > then be transformed into xhtml before sent). > Wiki syntax can be easily converted to html by the client. That's an implementation issue that would at best reached Best Practice status. > > > > > > > I'd be willing to relax our usage of the Text Module so that we > > > encourage more structural markup. As far as I can see, the > > > following elements would be most useful: > > > > > > blockquote > > > cite > > > em > > > q > > > strong > > > > yes. > > > > > > > In some applications I could also see an argument for: > > > > > > abbr > > > acronym > > > code > > > dfn > > > h1 through h6 > > > kbd > > > pre > > > Those are not forbidden in XHTML-IM right now, just not > > > encouraged. > > But > > > we could change that if we think it's a good idea. > > > > > > I'd say that or is important too. > > > > and the are quite usefull too. > > > > Also make the style attribute not REQUIRED, because it's probably > > the most > > complicated thing to implement. > > > > And the title attribute is interesting too on and stuff, so > > OPTIONAL > > would be better. > > > > -- > > Olivier > > > > As for I, if I stay in the optics of pure IM (i.e. when you chat fast > with people), I think the most interesting of them all are , > , ( is not so useful, because when I cite > stuffs mixed in my own sayings, in the context of IM, I would simply > use quotes "", This is a bit of personal preference. > whereas is very useful when you get a > big text separated); then nice but less important are lists > () and links (). List may be very good for multiline messages. Links are important, they should not be IMO automatic in HTML. > is nice also but for technical people mostly (and even for > technical stuffs, if I had no access to "code", I would use > "blockquote" instead, so this is not so primordial). > > And if we get structure in a more general way (for notification, not > only IM chatting), I would add all the title () tags, and > then I would add here. > > These are the main tags, at least as far as I am concerned. > > Jehan I personally am for structure as I would be the first one to turn off styling. Now I have to turn of the whole xhtml-im stuff. Pavel -- Web: http://www.pavlix.net/ Jabber & Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] Questions about xhtml-im
Olivier Goffart;2116 Wrote: > L > It could also make use of a WIKI-like syntax > Yes for my own, if really we are interested on client side text structuration, the wiki style is one of the best approach for technical users who don't like wysiwyg GUI, but still want to have full control of their structure. For my own, I find it very boring and slow to have to write xml tags or for emphasing, whereas the wiki style is as powerful, but very fast to write (nearly no difference with unformated writing, and especially no special character like <, >, /, etc.), nice to read while still unsent, and accurate. Writing ''emphasing'' is better than writing emphasing!!! And lists with * or # are so "obvious", whereas boring to write and it is easy to make a mistake of unclosed tags. But still for most end users, the best is wysiwyg (they are not willing to learn formatting rules, even as obvious as wiki ones), so they don't care whether it is wiki or html "under" the skull. Therefore I guess xhtml is a good choice for the finale formatting inside the XMPP stream, because it is XML as XMPP, and wiki-style could be used client-side as an implementation choice (which would then be transformed into xhtml before sent). > > > > I'd be willing to relax our usage of the Text Module so that we > > encourage more structural markup. As far as I can see, the following > > elements would be most useful: > > > > blockquote > > cite > > em > > q > > strong > > yes. > > > > In some applications I could also see an argument for: > > > > abbr > > acronym > > code > > dfn > > h1 through h6 > > kbd > > pre > > Those are not forbidden in XHTML-IM right now, just not encouraged. > But > > we could change that if we think it's a good idea. > > > I'd say that or is important too. > > and the are quite usefull too. > > Also make the style attribute not REQUIRED, because it's probably the > most > complicated thing to implement. > > And the title attribute is interesting too on and stuff, so > OPTIONAL > would be better. > > -- > Olivier > As for I, if I stay in the optics of pure IM (i.e. when you chat fast with people), I think the most interesting of them all are , , ( is not so useful, because when I cite stuffs mixed in my own sayings, in the context of IM, I would simply use quotes "", whereas is very useful when you get a big text separated); then nice but less important are lists () and links (). is nice also but for technical people mostly (and even for technical stuffs, if I had no access to "code", I would use "blockquote" instead, so this is not so primordial). And if we get structure in a more general way (for notification, not only IM chatting), I would add all the title () tags, and then I would add here. These are the main tags, at least as far as I am concerned. Jehan -- Jehan Jehan's Profile: http://www.jabberforum.org/member.php?userid=16911 View this thread: http://www.jabberforum.org/showthread.php?t=435
Re: [Standards] Questions about xhtml-im
Le mercredi 30 juillet 2008, Peter Saint-Andre a écrit : > Jehan wrote: > > Anyway for the part about semantic/structure versus style/display, > > probably there can be discussions about this (and you already had > > apparently), but even though I am completely partisan of structure, I > > understood well the two points here which are that this XEP is for IM, > > and that normal users cannot be asked to think about structure when they > > just care about style. I am also partisent of the structure. Currently, most client supporting HTML-IM are just focussed on the style, providing a toolbar with colors/fonts This can be nice for few fancy stuff, but a more interesting thing is to emphase the text. A better approach would be to have a toolbar with sementic buttons such as 'emphasis', 'code', 'citation'. It could also make use of a WIKI-like syntax > I'd be willing to relax our usage of the Text Module so that we > encourage more structural markup. As far as I can see, the following > elements would be most useful: > > blockquote > cite > em > q > strong yes. > In some applications I could also see an argument for: > > abbr > acronym > code > dfn > h1 through h6 > kbd > pre > Those are not forbidden in XHTML-IM right now, just not encouraged. But > we could change that if we think it's a good idea. I'd say that or is important too. and the are quite usefull too. Also make the style attribute not REQUIRED, because it's probably the most complicated thing to implement. And the title attribute is interesting too on and stuff, so OPTIONAL would be better. -- Olivier signature.asc Description: This is a digitally signed message part.
Re: [Standards] Questions about xhtml-im
Jehan wrote:
Peter Saint-Andre;1984 Wrote:
Please quote the entire section:
***
A user agent that implements this specification MUST conform to Section
3.5 ("XHTML Family User Agent Conformance") of Modularization of XHTML.
Many of the requirements defined therein are already met by Jabber
clients simply because they already include XML parsers.
However, "ignore" has a special meaning in XHTML modularization
(different from its meaning in XMPP). Specifically, criteria 4 through
6
of Section 3.5 of Modularization of XHTML state:
4.
W3C TEXT: If a user agent encounters an element it does not
recognize, it must continue to process the children of that element. If
the content is text, the text must be presented to the user.
XSF COMMENT: This behavior is different from that defined by
XMPP
Core, and in the context of XHTML-IM implementations applies only to
XML
elements qualified by the 'http://www.w3.org/1999/xhtml' namespace as
defined herein. This criterion MUST be applied to all XHTML 1.0
elements
except those explicitly included in XHTML-IM as described in the
XHTML-IM Integration Set and Recommended Profile sections of this
document. Therefore, an XHTML-IM implementation MUST process all XHTML
1.0 child elements of the XHTML-IM element even if such child
elements are not included in the XHTML 1.0 Integration Set defined
herein, and MUST present to the recipient the XML character data
contained in such child elements.
***
What I understand is
that when I encounter a tag which I recognize as being xhtml, but
which
is not in the xhtml-im subset, then I must display it "as is"?
Let's say you receive this:
I like the Extensible Messaging and Presence Protocol
(XMPP).
In this case you would display the XML character data of the
element even though it's not part of the XHTML-IM integration set.
That's just one example.
/psa
Sorry I did not understand (or at least as much as the original).
Don't worry about that. XHTML modularization is a bit strange. :)
So when you write to "display the XML character data", you mean that
you just dump the tag element, and display its content ("XMPP") ?
So you display this:
I like the Extensible Messaging and Presence Protocol (XMPP)
This would look natural to me (and I think to have understood this is
also how the W3C recommends it for the core xhtml .
Correct.
Anyway for the part about semantic/structure versus style/display,
probably there can be discussions about this (and you already had
apparently), but even though I am completely partisan of structure, I
understood well the two points here which are that this XEP is for IM,
and that normal users cannot be asked to think about structure when they
just care about style.
Yet just to answer shortly about this point:
The style should come from the meaning of the tag, like in the web!
How so? Remember that we don't have external CSS here.
In case where structure would have been chosen above style (even
though, as I remind, I understand now why style is chosen in IM), there
may be a small CSS just for the few available tags in xhtml-im on client
side (then a user could even modify their personal CSS).
Well, I agree with you about structural markup and I don't remember the
discussions that led to a more stylistic focus in XEP-0071. I think
people argued that users really want to send (say) italicized text, not
emphasized text. I'm sure we could check out the list archives for
historical details, but the real question is: how do we want to proceed now?
I'd be willing to relax our usage of the Text Module so that we
encourage more structural markup. As far as I can see, the following
elements would be most useful:
blockquote
cite
em
q
strong
In some applications I could also see an argument for:
abbr
acronym
code
dfn
h1 through h6
kbd
pre
Those are not forbidden in XHTML-IM right now, just not encouraged. But
we could change that if we think it's a good idea.
/psa
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [Standards] Questions about xhtml-im
On Wed, 30 Jul 2008 13:04:33 +0200
Jehan <[EMAIL PROTECTED]> wrote:
>
> Peter Saint-Andre;1984 Wrote:
> >
> > Please quote the entire section:
> >
> > ***
> >
> > A user agent that implements this specification MUST conform to
> > Section
> >
> > 3.5 ("XHTML Family User Agent Conformance") of Modularization of
> > XHTML.
> >
> > Many of the requirements defined therein are already met by Jabber
> > clients simply because they already include XML parsers.
> >
> > However, "ignore" has a special meaning in XHTML modularization
> > (different from its meaning in XMPP). Specifically, criteria 4
> > through 6
> > of Section 3.5 of Modularization of XHTML state:
> >
> > 4.
> >
> > W3C TEXT: If a user agent encounters an element it does not
> > recognize, it must continue to process the children of that
> > element. If
> >
> > the content is text, the text must be presented to the user.
> >
> > XSF COMMENT: This behavior is different from that defined by
> > XMPP
> > Core, and in the context of XHTML-IM implementations applies only to
> > XML
> > elements qualified by the 'http://www.w3.org/1999/xhtml' namespace
> > as defined herein. This criterion MUST be applied to all XHTML 1.0
> > elements
> > except those explicitly included in XHTML-IM as described in the
> > XHTML-IM Integration Set and Recommended Profile sections of this
> > document. Therefore, an XHTML-IM implementation MUST process all
> > XHTML
> >
> > 1.0 child elements of the XHTML-IM element even if such
> > child elements are not included in the XHTML 1.0 Integration Set
> > defined herein, and MUST present to the recipient the XML character
> > data contained in such child elements.
> >
> > ***
> >
> > > What I understand is
> > > that when I encounter a tag which I recognize as being xhtml, but
> > which
> > > is not in the xhtml-im subset, then I must display it "as is"?
> >
> > Let's say you receive this:
> >
> > I like the Extensible Messaging and Presence
> > Protocol (XMPP).
> >
> > In this case you would display the XML character data of the
> > element even though it's not part of the XHTML-IM
> > integration set.
> >
> > That's just one example.
> >
> > /psa
>
> Sorry I did not understand (or at least as much as the original).
>
> So when you write to "display the XML character data", you mean that
> you just dump the tag element, and display its content ("XMPP") ?
> So you display this:
> > I like the Extensible Messaging and Presence Protocol (XMPP)
>
> This would look natural to me (and I think to have understood this is
> also how the W3C recommends it for the core xhtml .
>
> Or do you mean that you display the unknown (in xhtml-im subset) tag
> element itself to the simple user view, so this:
> > I like the Extensible Messaging and Presence Protocol
> > (XMPP)
>
> So one will see unprocessed tag (and if the user does not know what is
> xhtml, it would look like strange unknown words)...
>
> I am sorry if I don't understand this... That's probably about word
> definition here where I am not sure about what you call the XML
> character data of an element:
> 1/ character data in XML being the "normal" text between the tag
> elements;
That's it.
> 2/ or character data as a graphical character/pictogram in an alphabet
> (what we call a "character set" in computer science)?
> Thanks.
>
> Jehan
>
> P.S.: for the rest of my questions, thanks for the answers. I guess I
> shall read and try and understand the concept of modularization of
> xhtml, as you suggest. :-)
>
> Anyway for the part about semantic/structure versus style/display,
> probably there can be discussions about this (and you already had
> apparently), but even though I am completely partisan of structure, I
> understood well the two points here which are that this XEP is for IM,
> and that normal users cannot be asked to think about structure when
> they just care about style.
>
> Yet just to answer shortly about this point:
> > > The style should come from the meaning of the tag, like in the
> > > web!
> >
> > How so? Remember that we don't have external CSS here.
>
> In case where structure would have been chosen above style (even
> though, as I remind, I understand now why style is chosen in IM),
> there may be a small CSS just for the few available tags in xhtml-im
> on client side (then a user could even modify their personal CSS).
>
>
I cannot talk for XHTML-IM as it's the first thing I turn off. But I
generally like the idea of using and and similar for
structural markup even in instant messaging.
It's markup vs. styling. I particularly dislike any styling... as this
will be often misused to put bright colors or fancy fonts into the
chatrooms which is annoying and...
If you see it... it's bad.
If you don't, you can't kick the people for huge font sizes, big fancy
pictures. For me xhtml-im is just a headache.
But... if I could disable the styling and use it for murkup like
emphasizing, links or even structuring s
Re: [Standards] Questions about xhtml-im
Peter Saint-Andre;1984 Wrote:
>
> Please quote the entire section:
>
> ***
>
> A user agent that implements this specification MUST conform to Section
>
> 3.5 ("XHTML Family User Agent Conformance") of Modularization of XHTML.
>
> Many of the requirements defined therein are already met by Jabber
> clients simply because they already include XML parsers.
>
> However, "ignore" has a special meaning in XHTML modularization
> (different from its meaning in XMPP). Specifically, criteria 4 through
> 6
> of Section 3.5 of Modularization of XHTML state:
>
> 4.
>
> W3C TEXT: If a user agent encounters an element it does not
> recognize, it must continue to process the children of that element. If
>
> the content is text, the text must be presented to the user.
>
> XSF COMMENT: This behavior is different from that defined by
> XMPP
> Core, and in the context of XHTML-IM implementations applies only to
> XML
> elements qualified by the 'http://www.w3.org/1999/xhtml' namespace as
> defined herein. This criterion MUST be applied to all XHTML 1.0
> elements
> except those explicitly included in XHTML-IM as described in the
> XHTML-IM Integration Set and Recommended Profile sections of this
> document. Therefore, an XHTML-IM implementation MUST process all XHTML
>
> 1.0 child elements of the XHTML-IM element even if such child
> elements are not included in the XHTML 1.0 Integration Set defined
> herein, and MUST present to the recipient the XML character data
> contained in such child elements.
>
> ***
>
> > What I understand is
> > that when I encounter a tag which I recognize as being xhtml, but
> which
> > is not in the xhtml-im subset, then I must display it "as is"?
>
> Let's say you receive this:
>
> I like the Extensible Messaging and Presence Protocol
> (XMPP).
>
> In this case you would display the XML character data of the
> element even though it's not part of the XHTML-IM integration set.
>
> That's just one example.
>
> /psa
Sorry I did not understand (or at least as much as the original).
So when you write to "display the XML character data", you mean that
you just dump the tag element, and display its content ("XMPP") ?
So you display this:
> I like the Extensible Messaging and Presence Protocol (XMPP)
This would look natural to me (and I think to have understood this is
also how the W3C recommends it for the core xhtml .
Or do you mean that you display the unknown (in xhtml-im subset) tag
element itself to the simple user view, so this:
> I like the Extensible Messaging and Presence Protocol
> (XMPP)
So one will see unprocessed tag (and if the user does not know what is
xhtml, it would look like strange unknown words)...
I am sorry if I don't understand this... That's probably about word
definition here where I am not sure about what you call the XML
character data of an element:
1/ character data in XML being the "normal" text between the tag
elements;
2/ or character data as a graphical character/pictogram in an alphabet
(what we call a "character set" in computer science)?
Thanks.
Jehan
P.S.: for the rest of my questions, thanks for the answers. I guess I
shall read and try and understand the concept of modularization of
xhtml, as you suggest. :-)
Anyway for the part about semantic/structure versus style/display,
probably there can be discussions about this (and you already had
apparently), but even though I am completely partisan of structure, I
understood well the two points here which are that this XEP is for IM,
and that normal users cannot be asked to think about structure when they
just care about style.
Yet just to answer shortly about this point:
> > The style should come from the meaning of the tag, like in the web!
>
> How so? Remember that we don't have external CSS here.
In case where structure would have been chosen above style (even
though, as I remind, I understand now why style is chosen in IM), there
may be a small CSS just for the few available tags in xhtml-im on client
side (then a user could even modify their personal CSS).
--
Jehan
Jehan's Profile: http://www.jabberforum.org/member.php?userid=16911
View this thread: http://www.jabberforum.org/showthread.php?t=435
Re: [Standards] Questions about xhtml-im
Jehan wrote:
Hello,
I try to understand the logic of 'xhtml-im'
(http://www.xmpp.org/extensions/xep-0071.html). Is there anyone nice
enough to explain me the following points please? :-)
1/ Section 4: > Lightweight text markup is then provided within an
element
qualified by the 'http://jabber.org/protocol/xhtml-im' namespace. [14]
However, this element is used solely as a "wrapper" for the
XHTML content itself, which content is encapsulated via one or more
elements qualified by the 'http://www.w3.org/1999/xhtml'
namespace, along with appropriate child elements thereof.
So why is the xhtml-im namespace for here if it is not used at all (as
the direct and only son is under the normal html namespace)? This is
maybe a stupid question as I think I have still not understood the
complete logic behing the xml namespaces...
Or should its role be to "tell" (through its schema?) which subset of
xhtml is authorized in it?
Right. The 'http://jabber.org/protocol/xhtml-im' namespace lets you know
that this is the XHTML-IM integration set, not full XHTML or some other
subset.
Now the real and more important issues I have:
To understand XEP-0071, you need to know that it is defined very
carefully in terms of XHTML modularization:
http://www.w3.org/TR/xhtml-modularization/
I think most of your confusion comes from the fact that you don't seem
to have grokked modularization.
2/ in 6.1, it is said that the structure module includes the elements
, (I guess this "html" means the one under the namespace
'http://www.w3.org/1999/xhtml', not the one under the namespace
'http://jabber.org/protocol/xhtml-im', doesn't it?) and .
That is true in XHTML itself.
But in
the meantime, it is said that under the XMPP (prefixed by
'http://jabber.org/protocol/xhtml-im') tag, you have only one or more
('http://www.w3.org/1999/xhtml').
Correct. Because we defined our own integration set.
Yet as far as I know (and as confirmed by any of the 'xhtml DTDs'
(http://www.w3.org/TR/xhtml1/#dtds) ), inside a body
('http://www.w3.org/1999/xhtml'), you cannot have any html
('http://www.w3.org/1999/xhtml'), head or even title tag.
Correct.
Hence I would think this is an error telling they are possible tags in
the xhtml-im subset of xhtml (as a consequence, it becomes useless to
unrecommend them in the section 7.1!). Or were you planning any other
wrapper element than ('http://jabber.org/protocol/xhtml-im') for
these tags?
No. Please read up on XHTML modularization. And yes I know that it's
confusing. Blame the W3C for that.
3/ Section 6.6, I don't understand what the Style attribute module
defines:
The Style Attribute Module is defined as including the style attribute
only, as included in the preceding definition tables.
It looks like there is no additional information that what already was
in other modules (which already included the "style" attribute for any
tag)...
So what is this "module" and its content?
http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_styleattributemodule
4/ Section 7, I don't understand the concept behind all the
"recommended profile" part. It looks like the whole important idea
behind xhtml-im here is solely style, not semantic! I mean, this is the
whole point of the importance given about "semantic web", and all the
work which has been done for the last years in the W3C to bring real
semantic to xhtml. And in our subset, we would want to remove all this
as not recommended and give higher priority to the absolutely not
semantic part? The main example is that the most important attribute for
all tag seems to be "style"!
This is for simple IM formatting. See the description of scope.
And several tags that I would think are very basic and important in a
definition of xhtml-im are not recommended, like "em", or "strong", or
all the titles tag "h1" to "h6", the cite and blockquote, etc.
-> You don't set text in bold or italic (which you can do with the
style attribute), you emphasize them!
-> You don't set a text with a bigger police, underline it and give it
a different police, no you set titles, subtitles, etc.
The style should come from the meaning of the tag, like in the web!
How so? Remember that we don't have external CSS here. :)
If you read the abstract of the xhtml 1 specif (linked from the XEP
-0071), the semantic is given a nice part:
This specification defines the Second Edition of XHTML 1.0, a
reformulation of HTML 4 as an XML 1.0 application, and three DTDs
corresponding to the ones defined by HTML 4. The semantics of the
elements and their attributes are defined in the W3C Recommendation for
HTML 4. These semantics provide the foundation for future extensibility
of XHTML. Compatibility with existing HTML user agents is possible by
following a small set of guidelines.
The web is becoming more and more semantic,
That can be debated. :)
this would be a shame XMPP, which is pretty new,
10 years old in 2009. :)
would not be semantic.
Re: [Standards] Questions about xhtml-im
Jeremy Bowers;1803 Wrote: > > That at least in terms of the IM users I deal with, people really *are* > "bolding" and "italicizing". You can tell by that fact that if you > shipped out an tag and the receiving client "chose" to interpret > that "semantic" as coloring it bright red for emphasis, you'd get a bug > filed against both clients for handling "italics" wrong. And that bug > report would indeed talk about "italics"; you'd never see a bug report > about how "I went to emphasize some text, but..." > > Making up semantics where there are none is as great a crime as failing > to expose them, if not greater. Sending out the presentation tags is the > semantically correct thing to do in a standardized rich-text IM context. > If you're not in that context, do something else; you're off the > xhtml-*IM* standard anyhow. See also requirement #1 of XEP-0071: > > "IM clients are not XHTML clients: their primary purpose is not to read > pre-existing XHTML documents, but to read and generate relatively large > numbers of fairly small instant messages." > Ok. Explained like this, you get a point. And now I understand the idea, and I can agree. It is not like I would prefer it for myself though, but it is understandable (when you consider most normal users). So I guess in another case, I would just use normal XHTML (for instance inside a pubsub notification event, I would not use xhtml-im, but normal xhtml). Then it answers 4/ and 5/ -> I simply was out of scope! But other points remains: especially I think 2/ is a functional bug of the XEP (at least in context of IM, it seems that you cannot use html, head and title tags). And the remaining points are questions about stuffs I am not 100% sure to understand... Jehan -- Jehan Jehan's Profile: http://www.jabberforum.org/member.php?userid=16911 View this thread: http://www.jabberforum.org/showthread.php?t=435
Re: [Standards] Questions about xhtml-im
Jehan said: > Of course, at the end, formatted text is presented to the peer, but > this is formatting done according to the semantic, not the opposite! > This is always the issue when people thought the "presentation" should > go first and then by sending a formatted text to a peer, this one > receives something unreadable with a completely different display that > what expected the sender, etc. The thing about semantics is that they don't exist in a vacuum; somebody had to intend them at some point. I'd suggest that when you said in your first message: > -> You don't set text in bold or italic (which you can do with the > style attribute), you emphasize them! > -> You don't set a text with a bigger police, underline it and give it > a different police, no you set titles, subtitles, etc. That at least in terms of the IM users I deal with, people really *are* "bolding" and "italicizing". You can tell by that fact that if you shipped out an tag and the receiving client "chose" to interpret that "semantic" as coloring it bright red for emphasis, you'd get a bug filed against both clients for handling "italics" wrong. And that bug report would indeed talk about "italics"; you'd never see a bug report about how "I went to emphasize some text, but..." Making up semantics where there are none is as great a crime as failing to expose them, if not greater. Sending out the presentation tags is the semantically correct thing to do in a standardized rich-text IM context. If you're not in that context, do something else; you're off the xhtml-*IM* standard anyhow. See also requirement #1 of XEP-0071: "IM clients are not XHTML clients: their primary purpose is not to read pre-existing XHTML documents, but to read and generate relatively large numbers of fairly small instant messages." -- Barracuda Networks makes the best spam firewalls and web filters. www.barracudanetworks.com
Re: [Standards] Questions about xhtml-im
Maciek Niedzielski;1791 Wrote:
>
> On the other hand, note that - while web is mostly HTML, and this HTML
>
> needs to contain everything - XMPP is about XML.
>
And I think XMPP also can contain anything as long as you define these
things. This is why it is about semantic, not rendering ("style"
attribute is only about rendering).
>
> So if you want to send
> notifications, you use XML namespace designed to send notifications.
> And
> when you want to send user readable text message with formatting, you
> can use XML designed for this, which is XHTML.
>
Of course you use the namespace designed for it! This is not opposed!
Inside a notification, you can have also readable text message with
formatting! For instance, under a prefixed under namespace
'http://jabber.org/protocol/pubsub#event', you 'may have Atom'
(http://tinyurl.com/6k8anf) (prefixed under
'http://www.w3.org/2005/Atom'), like proposed in example in the
XEP-0060. But it can also have many other sort of payload, and for
instance xhtml-im payload: 'here'
(http://wiki.jabber.org/index.php/PubSub_message_types), there are many
examples of pubsub kind of events with many different payload
namespace.
As a conclusion, of course you will use the proper pubsub#event
namespace, but inside you have freedom of payload. And it could be
xhtml-im for the readable text. Both concepts are not opposed.
>
> We want XHTML to format text, not to put there all data we wish to send
>
> and then think how to mark it correctly so that other peer guess its
> semantic meaning.
>
> --
> Maciek
> xmpp:machekku (AT) uaznia (DOT) net
>
Of course, at the end, formatted text is presented to the peer, but
this is formatting done according to the semantic, not the opposite!
This is always the issue when people thought the "presentation" should
go first and then by sending a formatted text to a peer, this one
receives something unreadable with a completely different display that
what expected the sender, etc.
Haven't you ever experienced the problem when sending a file generated
by a text processor (Word, OpenOffice...) with the common habit of
people making title as bold with some police, going to lines and pages
by hand thinking it is nicer, etc. But then on another machine/version
of the program/with other polices/etc. you get something without any
structural logic.
And this is also the main issue of the web as a whole at the beginning,
reason why now it is recommending semantic more and more to fix most
issues.
Jehan
--
Jehan
Jehan's Profile: http://www.jabberforum.org/member.php?userid=16911
View this thread: http://www.jabberforum.org/showthread.php?t=435
Re: [Standards] Questions about xhtml-im
Jehan wrote: The web is becoming more and more semantic, this would be a shame XMPP, which is pretty new, would not be semantic... 5/ Linked to the previous point, this XEP seems to describe XMPP usage only for IM point of view, but it has other usages now For instance, there can be notifications, textual data exchange, and most probably other cases... And for this, we may need to structure text (which then can be rendered according to the given structure!). On the other hand, note that - while web is mostly HTML, and this HTML needs to contain everything - XMPP is about XML. So if you want to send notifications, you use XML namespace designed to send notifications. And when you want to send user readable text message with formatting, you can use XML designed for this, which is XHTML. We want XHTML to format text, not to put there all data we wish to send and then think how to mark it correctly so that other peer guess its semantic meaning. -- Maciek xmpp:[EMAIL PROTECTED]
[Standards] Questions about xhtml-im
Hello,
I try to understand the logic of 'xhtml-im'
(http://www.xmpp.org/extensions/xep-0071.html). Is there anyone nice
enough to explain me the following points please? :-)
1/ Section 4: > Lightweight text markup is then provided within an
element
> qualified by the 'http://jabber.org/protocol/xhtml-im' namespace. [14]
> However, this element is used solely as a "wrapper" for the
> XHTML content itself, which content is encapsulated via one or more
> elements qualified by the 'http://www.w3.org/1999/xhtml'
> namespace, along with appropriate child elements thereof.
So why is the xhtml-im namespace for here if it is not used at all (as
the direct and only son is under the normal html namespace)? This is
maybe a stupid question as I think I have still not understood the
complete logic behing the xml namespaces...
Or should its role be to "tell" (through its schema?) which subset of
xhtml is authorized in it?
Now the real and more important issues I have:
2/ in 6.1, it is said that the structure module includes the elements
, (I guess this "html" means the one under the namespace
'http://www.w3.org/1999/xhtml', not the one under the namespace
'http://jabber.org/protocol/xhtml-im', doesn't it?) and . But in
the meantime, it is said that under the XMPP (prefixed by
'http://jabber.org/protocol/xhtml-im') tag, you have only one or more
('http://www.w3.org/1999/xhtml').
Yet as far as I know (and as confirmed by any of the 'xhtml DTDs'
(http://www.w3.org/TR/xhtml1/#dtds) ), inside a body
('http://www.w3.org/1999/xhtml'), you cannot have any html
('http://www.w3.org/1999/xhtml'), head or even title tag.
Hence I would think this is an error telling they are possible tags in
the xhtml-im subset of xhtml (as a consequence, it becomes useless to
unrecommend them in the section 7.1!). Or were you planning any other
wrapper element than ('http://jabber.org/protocol/xhtml-im') for
these tags?
3/ Section 6.6, I don't understand what the Style attribute module
defines:
> The Style Attribute Module is defined as including the style attribute
> only, as included in the preceding definition tables.
It looks like there is no additional information that what already was
in other modules (which already included the "style" attribute for any
tag)...
So what is this "module" and its content?
4/ Section 7, I don't understand the concept behind all the
"recommended profile" part. It looks like the whole important idea
behind xhtml-im here is solely style, not semantic! I mean, this is the
whole point of the importance given about "semantic web", and all the
work which has been done for the last years in the W3C to bring real
semantic to xhtml. And in our subset, we would want to remove all this
as not recommended and give higher priority to the absolutely not
semantic part? The main example is that the most important attribute for
all tag seems to be "style"!
And several tags that I would think are very basic and important in a
definition of xhtml-im are not recommended, like "em", or "strong", or
all the titles tag "h1" to "h6", the cite and blockquote, etc.
-> You don't set text in bold or italic (which you can do with the
style attribute), you emphasize them!
-> You don't set a text with a bigger police, underline it and give it
a different police, no you set titles, subtitles, etc.
The style should come from the meaning of the tag, like in the web!
If you read the abstract of the xhtml 1 specif (linked from the XEP
-0071), the semantic is given a nice part:
> This specification defines the Second Edition of XHTML 1.0, a
> reformulation of HTML 4 as an XML 1.0 application, and three DTDs
> corresponding to the ones defined by HTML 4. The semantics of the
> elements and their attributes are defined in the W3C Recommendation for
> HTML 4. These semantics provide the foundation for future extensibility
> of XHTML. Compatibility with existing HTML user agents is possible by
> following a small set of guidelines.
The web is becoming more and more semantic, this would be a shame XMPP,
which is pretty new, would not be semantic...
5/ Linked to the previous point, this XEP seems to describe XMPP usage
only for IM point of view, but it has other usages now:
>
> Even within the restricted set of modules specified as defining the
> XHTML-IM Integration Set (see preceding section), some elements and
> attributes are inappropriate or unnecessary for the purpose of instant
> messaging
>
For instance, there can be notifications, textual data exchange, and
most probably other cases... And for this, we may need to structure text
(which then can be rendered according to the given structure!).
6/ In section 12.2, when you explain the meaning of "ignoring" an
element, I can read:
>
> Therefore, an XHTML-IM implementation MUST process all XHTML 1.0 child
> elements of the XHTML-IM element even if such child elements are
> not included in the XHTML 1.0 Integration Set defined herein, and MUST
> present to the recipient the
