Re: Major backtracking on canonicalization

[Paul Hoffman]

At 2:25 PM -0400 7/11/05, Karl Dubost wrote:

I read
Just as with [XML-C14N] one may use the "#WithComments"
parameter to include the serialization of XML comments.

So it's a MAY, but it doesn't say that when the parameter is not 
here that there's a MUST NOT include them.


H, that's not how I read it at all. Given that we are talking 
about a canonicalization spec that has to say exactly what is and is 
not in the converted, I would find it surprising to have something 
that means "this may or may not appear in the output, you don't know".


ok, so it's not really a default feature/behaviour but it seems 
something like a flag that you have to give.


Agree.

--Paul Hoffman, Director
--Internet Mail Consortium

More while we're waiting discussion

[James M Snell]

While we're waiting for more feedback on the format spec, I've been 
stewing over a number of extension ideas whatcha think?


The first is rather simple.  It defines an expires element that can be 
applied to a feed or an entry.  I have described the basics @ 
http://www.snellspace.com/wp/?p=174 but am reconsidering that blog 
entries description of how an expires element on the feed interacts with 
an expires element in an entry within the feed.  The element is a Date 
construct that specifies the instant (inclusive) that the entry or feed 
"expires".  This is useful for feeds or entries that contain 
time-sensitive content -- such as special offerings from e-commerce 
sites, "top-ten" lists, etc. 


  
 ...
 2005-07-12T12:00:00Z
 
...
2005-07-12T12:00:00Z
 
  


The second extension is a comments link type that allows an entry to be 
associated with a separate feed containing comments.  It is described @ 
http://www.snellspace.com/wp/?p=185.  There is an existing RSS-based 
equivalent already in use described @ 
http://www.sellsbrothers.com/spout/#exposingRssComments.  It would be 
possible to reuse that existing mechanism but it's rather specific to RSS.


  
 
http://example.com/commentsfeed.xml"; />
 
  

The third is a non-RDF adaptation of the Creative Commons RSS 1.0 Module 
that uses the Atom link element and provides a machine readable license 
for entries and feeds. It is described @ 
http://www.snellspace.com/wp/?p=184.


  
 http://www.creativecommons.org/licenses/by-nc/1.0";
  xmlns:lic="...">
{URI}
{URI}
 
  

Thoughts?

- James

FormatTests

[Sam Ruby]

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

I've taken a pass at enumerating the test cases required to validate 
Atom 1.0, based on the presumption that things are not going to change 
too drastically from draft-ietf-atompub-format-09.


Undoubtedly there are typos, bugs, omissions, and there might even be an 
occasion or two where I have been overzealous.


My experience has been that this is only a starter set at best, as the 
set of possible errors that people will attempt is well beyond anything 
that one can possibly anticipate.


Corrections welcome.

- Sam Ruby

Re: Old application/atom+xml issues

[Bill de hÓra]

Robert Sayre wrote:

> I worry that any statement like Bill's suggested text will confer
> legitimacy on Atom 0.3 as long as the RFC is available. *Every*
> current implementor is aware of the issue, so the short term benefit
> of such text is pretty much nil. Long term, the text will actually be
> harmful.

+1 to this sentiment - I take it this means we're saying no to the
interop text in the spec?

Re: Old application/atom+xml issues

[Sam Ruby]

Robert Sayre wrote:


So, -1 to mentioning Atom 0.3 at all.


I agree with Robert.

Note how Atom 0.2 isn't a problem at all...  we can (and will) do the 
same thing with Atom 0.3.


- Sam Ruby

Re: Major backtracking on canonicalization

[Karl Dubost]

Le 05-07-07 à 14:12, Paul Hoffman a écrit :
Without. That is explicitly the default for .




Where does it state that explicitly?



"Just as with [XML-C14N] one may use the "#WithComments" parameter  
to include the serialization of XML comments." Meaning: if you  
don't include #WithComment, you don't get comments.


H. not sure.

[[[
4. Use in XML Security

Exclusive Canonicalization may be used as a Transform or  
CanonicalizationMethod algorithm in XML Digital Signature [XML-DSig]  
and XML Encryption [XML-Enc].


Identifier:
http://www.w3.org/2001/10/xml-exc-c14n#
http://www.w3.org/2001/10/xml-exc-c14n#WithComments

Just as with [XML-C14N] one may use the "#WithComments" parameter to  
include the serialization of XML comments. This algorithm also takes  
an optional explicit parameter of an empty InclusiveNamespaces  
element with a PrefixList attribute. The value of this attribute,  
which may be null, is a white space delimited list of namespace  
prefixes, and where #default indicates the default namespace, to be  
handled as per [XML-C14N]. The list is in NMTOKENS format (a white  
space separated list).


]]] - http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/#sec-Intro


I read
Just as with [XML-C14N] one may use the "#WithComments"
parameter to include the serialization of XML comments.

So it's a MAY, but it doesn't say that when the parameter is not here  
that there's a MUST NOT include them.


Going a bit further, because it is said "Just as with [XML-C14N]". I  
follow the link


[[[
The second parameter of input to the XML canonicalization method is a  
boolean flag indicating whether or not comments should be included in  
the canonical form output by the XML canonicalization method. If a  
canonical form contains comments corresponding to the comment nodes  
in the input node-set, the result is called canonical XML with  
comments. Note that the XPath data model does not create comment  
nodes for comments appearing within the document type declaration  
(DTD). Implementations are REQUIRED to be capable of producing  
canonical XML excluding all comments that may have appeared in the  
input document or document subset. Support for canonical XML with  
comments is RECOMMENDED.

]]] - http://www.w3.org/TR/2001/REC-xml-c14n-20010315#DataModel


ok, so it's not really a default feature/behaviour but it seems  
something like a flag that you have to give.




--
Karl Dubost - http://www.w3.org/People/karl/
W3C Conformance Manager
*** Be Strict To Be Cool ***

Re: Old application/atom+xml issues

[Robert Sayre]

> What Mark said. Now, that's the world as it might be outside the spec.
> There is still proposed spec text

There are also draft-05, draft-06, draft-07, draft-08, and draft-09
feeds in the wild, being produced by people who aren't WG members.
There are RSS feeds served as application/atom+xml.

All of these things are obviously invalid Atom 1.0, and MUST be
considered so, as they do not reside in the correct namespace. Someone
who's read the spec is in no danger of mistaking an Atom 0.3 feed for
an Atom 1.0, and no software that bothers to check the namespace of
the root element will be fooled.

I worry that any statement like Bill's suggested text will confer
legitimacy on Atom 0.3 as long as the RFC is available. *Every*
current implementor is aware of the issue, so the short term benefit
of such text is pretty much nil. Long term, the text will actually be
harmful.

So, -1 to mentioning Atom 0.3 at all.

Robert Sayre

Re: Old application/atom+xml issues

[Bill Kearney]

> [[[
> Interoperability considerations: Some existing agents and feeds that
> support the Atom 0.3 specification make use of this media type despite
> Atom 0.3 not being compatible with Atom 1.0. Such feeds SHOULD be
> considered invalid Atom 1.0.
> ]]]

Seems reasonable.  When 1.0 goes final we'll be flipping the switch on
Syndic8 to start requiring it for a valid listing.  Not en-masse but in
pretty short order.  No sense "freaking anyone out" but we're not going to
go coddling things for very long.  Besides, all this is code or template
driven and is often quite easy to update.  It's being firm about pushing the
various things to update that's necessary.  And NOT wasting inordinate
amounts of time and message threads whinging about popular tools or sites
that "can't" be updated.  Tough, get with it.

-Bill Kearney
Syndic8.com

Re: Old application/atom+xml issues

[Bill de hÓra]

Mark Baker wrote:
> On Mon, Jul 11, 2005 at 09:59:19AM -0400, Sam Ruby wrote:
> 
>>The most we can do is to say that such things are invalid, and to work 
>>with the producers to correct this.
> 
> 
> Sounds good to me.
> 
> 
>>The majority of the existing atom 0.3 feeds are produced by a relatively 
>>few producers.  I am confident that these producers will convert over 
>>quickly.
>>
>>I am also committed to getting the word out quickly that atom 0.3 feeds 
>>are not to be considered valid.  In particular, I plan to update the 
>>feedvalidator to note this as a problem (first as a warning, and later I 
>>will change this to an error).
> 
> 
> Nice.  Thanks for your vigilance, Sam.

What Mark said. Now, that's the world as it might be outside the spec.
There is still proposed spec text, which I suggest is amended as follows:

[[[
Interoperability considerations: Some existing agents and feeds that
support the Atom 0.3 specification make use of this media type despite
Atom 0.3 not being compatible with Atom 1.0. Such feeds SHOULD be
considered invalid Atom 1.0.
]]]

cheers
Bill

Re: Old application/atom+xml issues

[Mark Baker]

On Mon, Jul 11, 2005 at 09:59:19AM -0400, Sam Ruby wrote:
> The most we can do is to say that such things are invalid, and to work 
> with the producers to correct this.

Sounds good to me.

> The majority of the existing atom 0.3 feeds are produced by a relatively 
> few producers.  I am confident that these producers will convert over 
> quickly.
> 
> I am also committed to getting the word out quickly that atom 0.3 feeds 
> are not to be considered valid.  In particular, I plan to update the 
> feedvalidator to note this as a problem (first as a warning, and later I 
> will change this to an error).

Nice.  Thanks for your vigilance, Sam.

Mark.
-- 
Mark Baker.  Ottawa, Ontario, CANADA.  http://www.markbaker.ca
Coactus; Web-inspired integration strategies   http://www.coactus.com

Re: Old application/atom+xml issues

[Sam Ruby]

Bill de hÓra wrote:

Mark Baker wrote:



IMO, it matters not that no spec prescribes the use of this media type
for Atom 0.3 feeds.  What matters is whether it's in use today, which
we seem to agree is the case.  This seems an important piece of
information that implementors should know, which is my motivation for
asking that it be called out in the "interoperability considerations"
section of the template.  Something like;

 Interoperability considerations: Some existing agents and feeds that
support the Atom 0.3 specification, make use of this media
 type despite Atom 0.3 not being compatible with Atom 1.0.


In the spirit of that point about 0.3 being served with the media type
being an interop issue - what are the behaviors which will lead to
interoperation? The above text is only leads one to ask "and I should do
what here?" and doesn't say anything useful about what to do.


I'll also point out that there are atom 0.3 feeds being served with a 
mime type of text/html.  And undoubtably there will be atom 1.0 feeds so 
served.


The most we can do is to say that such things are invalid, and to work 
with the producers to correct this.


The majority of the existing atom 0.3 feeds are produced by a relatively 
few producers.  I am confident that these producers will convert over 
quickly.


I am also committed to getting the word out quickly that atom 0.3 feeds 
are not to be considered valid.  In particular, I plan to update the 
feedvalidator to note this as a problem (first as a warning, and later I 
will change this to an error).


- Sam Ruby

Re: Old application/atom+xml issues

[Bill de hÓra]

Mark Baker wrote:

> IMO, it matters not that no spec prescribes the use of this media type
> for Atom 0.3 feeds.  What matters is whether it's in use today, which
> we seem to agree is the case.  This seems an important piece of
> information that implementors should know, which is my motivation for
> asking that it be called out in the "interoperability considerations"
> section of the template.  Something like;
> 
>   Interoperability considerations: Some existing agents and feeds that
>  support the Atom 0.3 specification, make use of this media
>type despite Atom 0.3 not being compatible with Atom 1.0.

In the spirit of that point about 0.3 being served with the media type
being an interop issue - what are the behaviors which will lead to
interoperation? The above text is only leads one to ask "and I should do
what here?" and doesn't say anything useful about what to do.

cheers
Bill

Re: I-D ACTION:draft-nottingham-atompub-feed-history-01.txt

[Bill de hÓra]

Mark Nottingham wrote:
> 
> On 04/07/2005, at 6:18 PM, Thomas Broyer wrote:
> 
>> Really good work!
> 
> 
> Thanks!
> 
> 
> 
>> Why not using an xs:boolean for fh:stateful? hence allowing values 0,
>> 1, true and false.
> 
> 
> I did it this way because I'm not a huge XML Schema fan :)
> 
> At this point, stateful is effectively xs:boolean with a constraint on
> the lexical space. I'm not against changing it to '"1" or "true" / "0"
> or "false", except that this makes the spec more verbose (but that's a
> pretty minor concern, properly managed). What do others think (in either
> direction)?

1. I don't want to have to link to an XSD library in my XML toolchain
just to process true/false in an attribute.

2. I don't want to hack some code together to recognize a single XSD
primitive just because I don't want to link to an XSD library.

cheers
Bill