Re: http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests

[James Holderness]

Robert Sayre wrote:

When XHTML content is used,

"The XHTML div element itself MUST NOT be considered part of the content."




FWIW, most aggregators that I've tested do not strip the div element.

Regards
James

Re: http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests

[James M Snell]

I'm shooting for at least five demerits. Otherwise, the week will be
completely sunk.  And yes, the parser would be conformant.  Abdera is
conformant even tho it is possible to use Abdera to produce and read
invalid Atom.  Returning the div in the "getContent" method is incorrect
and I'm fixing that now; making the div available for the application
using Abdera should be ok.  I want to make sure this conformance test
isn't saying that the parser must hide the div completely.

- James

Robert Sayre wrote:
> On 6/27/06, James M Snell <[EMAIL PROTECTED]> wrote:
>> Please define "conformance" in regards to this test.  That is, what is
>> the exact behavior that a library must perform when a code library has
>> an API like, "getContent" on the content element.
>>
>> e.g., is a parser not conformant if it passes the DIV on to the
>> consuming application with the expectation that the application is
>> responsible for "doing the right thing" with it?
> 
> Don't be dense. Would the parser be conformant if it passed on the
> feed, entry, and div elements with that expectation? I'll file a bug
> on UFP and I bet you it'll get fixed without a question, because there
> won't be a bad-faith interpretation to fight. That's two demerits this
> week for you. Tsk tsk.
> 

Re: http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests

[Robert Sayre]

On 6/27/06, James M Snell <[EMAIL PROTECTED]> wrote:

Please define "conformance" in regards to this test.  That is, what is
the exact behavior that a library must perform when a code library has
an API like, "getContent" on the content element.

e.g., is a parser not conformant if it passes the DIV on to the
consuming application with the expectation that the application is
responsible for "doing the right thing" with it?


Don't be dense. Would the parser be conformant if it passed on the
feed, entry, and div elements with that expectation? I'll file a bug
on UFP and I bet you it'll get fixed without a question, because there
won't be a bad-faith interpretation to fight. That's two demerits this
week for you. Tsk tsk.

--

Robert Sayre

"I would have written a shorter letter, but I did not have the time."

Re: http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests

[James M Snell]

Please define "conformance" in regards to this test.  That is, what is
the exact behavior that a library must perform when a code library has
an API like, "getContent" on the content element.

e.g., is a parser not conformant if it passes the DIV on to the
consuming application with the expectation that the application is
responsible for "doing the right thing" with it?

Robert Sayre wrote:
> 
> When XHTML content is used,
> 
> "The XHTML div element itself MUST NOT be considered part of the content."
> 
> 
> 
> 
> 
> This is hard to test with aggregators, but conforming libraries
> definitely need to get this right.
> 
> http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests
> 

Re: [Fwd: I-D ACTION:draft-saintandre-atompub-notify-05.txt]

[Peter Saint-Andre]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

FYI, the underlying XMPP publish-subscribe spec has been updated as well:

http://mail.jabber.org/pipermail/standards-jig/2006-June/011643.html

Peter

Sylvain Hellegouarch wrote:
> Nice work Peter. Very nice.
> 
> Peter Saint-Andre a écrit :
>> FYI...
>>
>>
>>  Original Message 
>> Subject: I-D ACTION:draft-saintandre-atompub-notify-05.txt
>> Date: Mon, 26 Jun 2006 18:50:01 -0400
>> From: [EMAIL PROTECTED]
>> Reply-To: [EMAIL PROTECTED]
>> To: i-d-announce@ietf.org
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>
>>
>> Title: Transporting Atom Notifications over the Extensible
>> Messaging
>> and Presence Protocol (XMPP)
>> Author(s): P. Saint-Andre, et al.
>> Filename: draft-saintandre-atompub-notify-05.txt
>> Pages: 17
>> Date: 2006-6-26
>> 
>> This memo describes a method for notifying interested parties about
>>changes in syndicated information encapsulated in the Atom feed
>>format, where such notifications are delivered via an extension to
>>the Extensible Messaging and Presence Protocol (XMPP) for publish-
>>subscribe functionality.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-saintandre-atompub-notify-05.txt
>>
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEoa5jNF1RSzyt3NURAo0BAJwPVdqCNgkyvQ9CMx4Zp9cGvwgl7wCdGiCG
Mvo2dh9OPsPugw6WzHAmRfQ=
=5JX4
-END PGP SIGNATURE-


smime.p7s
Description: S/MIME Cryptographic Signature

http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests

[Robert Sayre]

When XHTML content is used,

"The XHTML div element itself MUST NOT be considered part of the content."





This is hard to test with aggregators, but conforming libraries
definitely need to get this right.

http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests

--

Robert Sayre

Re: [Fwd: I-D ACTION:draft-saintandre-atompub-notify-05.txt]

[Sylvain Hellegouarch]

Nice work Peter. Very nice.

Peter Saint-Andre a écrit :

FYI...


 Original Message 
Subject: I-D ACTION:draft-saintandre-atompub-notify-05.txt
Date: Mon, 26 Jun 2006 18:50:01 -0400
From: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: i-d-announce@ietf.org

A New Internet-Draft is available from the on-line Internet-Drafts
directories.


Title   : Transporting Atom Notifications over the Extensible 
Messaging
and Presence Protocol (XMPP)
Author(s)   : P. Saint-Andre, et al.
Filename: draft-saintandre-atompub-notify-05.txt
Pages   : 17
Date: 2006-6-26

This memo describes a method for notifying interested parties about
   changes in syndicated information encapsulated in the Atom feed
   format, where such notifications are delivered via an extension to
   the Extensible Messaging and Presence Protocol (XMPP) for publish-
   subscribe functionality.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-saintandre-atompub-notify-05.txt

To remove yourself from the I-D Announcement list, send a message to
[EMAIL PROTECTED] with the word unsubscribe in the body of
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-saintandre-atompub-notify-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
[EMAIL PROTECTED]
In the body type:
"FILE /internet-drafts/draft-saintandre-atompub-notify-05.txt".

NOTE:   The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility.  To use this
feature, insert the command "ENCODING mime" before the "FILE"
command.  To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader.  Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.


Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.


  



Content-Type: text/plain
Content-ID: <[EMAIL PROTECTED]>


  



___
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/i-d-announce

  

Re: [RFC 4287] unicity of atom:category element

[Robert Sayre]

On 6/27/06, James M Snell <[EMAIL PROTECTED]> wrote:


Slight addition to this,

The scheme not only disambiguates the term, it also identifies the means
of interpreting the term.  For instance, Tim Bray's feed uses a
scheme/term combo that can be concatenated to form a meaningful,
dereferencable URI.


There's no spec text to back this up. A convention might emerge, but
let's not BS it.

--

Robert Sayre

"I would have written a shorter letter, but I did not have the time."

Re: [RFC 4287] unicity of atom:category element

[James M Snell]

Slight addition to this,

The scheme not only disambiguates the term, it also identifies the means
of interpreting the term.  For instance, Tim Bray's feed uses a
scheme/term combo that can be concatenated to form a meaningful,
dereferencable URI.

- James

Laurent Le Meur wrote:
>>> Could an atom 1.0 feed contain some item whith
>>> ">> somexmlns:href='http://www.tbray.org/ongoing/What/Technology/Coding/Java/'
>> />
>>> and other item with
>>> ">> somexmlns:href='http://www.tbray.org/ongoing/What/Technology/Sun/Java/' />
>>> where the first Java is not the same as the second ?
>> The term is machine readable. The label is human readable.
>>
>> > scheme='http://www.example.org/cat/'
>> term='http://www.example.org/cat/Technology/Coding/Java/'
>> label='Java'
>> />
>> > scheme='http://www.exmple.org/'
>> term='http://www.example.org/cat/Technology/Sun/Java/'
>> label='Java'
>> />
>>
>> Regards,
>> Aristotle Pagaltzis // 
> 
> Aristotle,
> 
> I agree with your statement but feel your example somewhat misleading. From my
> understanding:
> 
> - A 'term' is a token (syntactically a string) used for indexing; in the 
> absence
> of an associated scheme it is processed as a free keyword/tag. There's no real
> reason to make it a URI, but it can be a number (eg ISBN code).
> 
> - A 'scheme' is the identifier of a controlled vocabulary = a set of terms. 
> It's
> an IRI. It is optional, but 'scopes' the term, so ambiguities are avoided. If
> present {scheme,term} is a tuple that unambiguously identifies a resource.
> {http://www.software.org/, java} and { http://www.island.org/ , java} are
> clearly different categories.
> 
> A note regarding the {scheme, code} tuple: the spec does not indicate how more
> information about the category can be found, using some form of concatenation 
> of
> the scheme URI + term.
> 
> - A 'label' is a human readable string associated with a category code (term).
> 
> A note regarding 'label':= limitations of the spec are:
> - it is not possible to represent several labels in different languages
> - it is not possible to apply i18n attributes like 'dir' to a label.
> 
> Best regards
> Laurent Le Meur
> AFP
> 
> 
> 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> 
> This e-mail, and any file transmitted with it, is confidential and  intended 
> solely for the use of the individual or entity to whom it is addressed. If 
> you have received this email in error, please  contact the sender and delete 
> the email from your system. If you are  not the named addressee you should 
> not disseminate, distribute or copy  this email.
> 
> For more information on Agence France-Presse, please visit our web site at 
> http://www.afp.com
> 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> 
> 

RE: [RFC 4287] unicity of atom:category element

[Laurent Le Meur]

> > Could an atom 1.0 feed contain some item whith
> > " > somexmlns:href='http://www.tbray.org/ongoing/What/Technology/Coding/Java/'
> />
> > and other item with
> > " > somexmlns:href='http://www.tbray.org/ongoing/What/Technology/Sun/Java/' />
> > where the first Java is not the same as the second ?
> 
> The term is machine readable. The label is human readable.
> 
>  scheme='http://www.example.org/cat/'
> term='http://www.example.org/cat/Technology/Coding/Java/'
> label='Java'
> />
>  scheme='http://www.exmple.org/'
> term='http://www.example.org/cat/Technology/Sun/Java/'
> label='Java'
> />
> 
> Regards,
> Aristotle Pagaltzis // 

Aristotle,

I agree with your statement but feel your example somewhat misleading. From my
understanding:

- A 'term' is a token (syntactically a string) used for indexing; in the absence
of an associated scheme it is processed as a free keyword/tag. There's no real
reason to make it a URI, but it can be a number (eg ISBN code).

- A 'scheme' is the identifier of a controlled vocabulary = a set of terms. It's
an IRI. It is optional, but 'scopes' the term, so ambiguities are avoided. If
present {scheme,term} is a tuple that unambiguously identifies a resource.
{http://www.software.org/, java} and { http://www.island.org/ , java} are
clearly different categories.

A note regarding the {scheme, code} tuple: the spec does not indicate how more
information about the category can be found, using some form of concatenation of
the scheme URI + term.

- A 'label' is a human readable string associated with a category code (term).

A note regarding 'label':= limitations of the spec are:
- it is not possible to represent several labels in different languages
- it is not possible to apply i18n attributes like 'dir' to a label.

Best regards
Laurent Le Meur
AFP



-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

This e-mail, and any file transmitted with it, is confidential and  intended 
solely for the use of the individual or entity to whom it is addressed. If you 
have received this email in error, please  contact the sender and delete the 
email from your system. If you are  not the named addressee you should not 
disseminate, distribute or copy  this email.

For more information on Agence France-Presse, please visit our web site at 
http://www.afp.com

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: [RFC 4287] unicity of atom:category element

[Thomas Broyer]

2006/6/26, Nicolas Krebs:

Excerpt quoted from section 4.2.2 of urn:ietf:rfc:4287
( http://tools.ietf.org/html/rfc4287#section-4.2.2 )

> 4.2.2.1.  The "term" Attribute

> The "term" attribute is a string that identifies the category

Is the term attribute an unique identifiers ?


My interpretation of atom:category is that scheme+term defines a
unique identifier, much the same as a QName in XML.
I might be wrong however, as RFC4287 is completely silent on this...


How can i manage the homonym ?


Use different categorization schemes ;-)


Could an atom 1.0 feed contain some item whith
"
and other item with
"


Yes.

Note that you could also have those two atom:category elements in the
same atom:entry, as RFC4287 puts no constraint at all on categories
(unlike atom:link elements).


where the first Java is not the same as the second ?


With the same scheme and term, aggregators (or other Atom processors)
are very likely to consider them the exact same category.
I think the producer of such a feed would be wrong using the same
scheme and term for (conceptually) different categories...

--
Thomas Broyer