Re: Current and permalink link rel values

[Bjoern Hoehrmann]

* Elliotte Harold wrote:
>By the way, http://www.iana.org/assignments/relation/ is 404. This is 
>referenced in the Atom 1.0 spec. It doesn't really need to be resolved, 
>but it would be nice to put something there.

Interesting. http://www.iana.org/assignments/link-relations.html is the
right address at the moment.
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: Quoting type parameter value allowed? - Was: I-D ACTION:draft-ietf-atompub-typeparam-00.txt

[Bjoern Hoehrmann]

* Andreas Sewe wrote:
>This raises the question, however, whether it would be worth pointing 
>out in the I-D that quoting a parameter value is allowed. Implementors 
>might otherwise produce code that does treat 
>application/atom+xml;type="feed" and application/atom+xml;type=feed as 
>different.
>
>James, can you add a note to this effect to your I-D? It doesn't do any 
>harm and might to be useful (at least to people like me ;-).

It actually does harm. First, unless carefully phrased that might be
misread to suggest application/atom+xml;type="'feed'" or similar is
allowed, and it would suggest a false sense of completeness. As an
example, RFC 2616 would also allow you to use type="f\eed" or use of
MIME word encoding in the quoted string ala type="=?...?=". It seems
this is better left to a test suite.
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: Quoting type parameter value allowed? - Was: I-D ACTION:draft-ietf-atompub-typeparam-00.txt

[Bjoern Hoehrmann]

* Andreas Sewe wrote:
>While RFC 2045 specifically allows quoted parameter values and defines 
>application/atom+xml;type="feed" to be equivalent to 
>application/atom+xml;type=feed, RFC 4288 states that '[t]here is no 
>defined syntax for parameter values. Therefore registrations MUST 
>specify parameter value syntax.'
>
>So, it looks like that quoting the type parameter's values is no longer 
>allowed; draft-ietf-atompub-typeparam-00.txt defines the following:
>
># type = "entry" / "feed"
>
>But is this intentional? And, even if backed by RFC 4288 (I think so) 
>and being intentional (I don't think so ;-), would it be worth to at 
>least add a note to the parameter registration which explicitly states 
>that quotes around "feed" or "entry" are disallowed?

You would apply the grammar above on the parameter value. In type="feed"
the parameter value is 'feed' which matches the grammar. Compare this to
XML attributes, if the attribute value must match /^[0-9]+$/ then you
also wouldn't conclude that the attribute value must not be "quoted".
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: Fwd: Atom format interpretation question

[Bjoern Hoehrmann]

* Bob Wyman wrote:
>Did the "+xml" convention ever get formalized in some RFC? I know we all
>*think* that tacking "+xml" onto the end of something means that it is some
>use of XML, however, if I remember correctly, this little bit of syntax has
>never actually been formalized... Or have I missed something? Is there an
>RFC that defines what "+xml" means?

RFC 3023 and RFC 4288.
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: Atom Syndication Format To Draft Standard?

[Bjoern Hoehrmann]

* Robert Sayre wrote:
>I think we should move the format to Draft Standard by clearing up any 
>errata and adding two attributes: 'dir' and 'unicode-bidi', as defined 
>in XHTML.
>
>Thoughts?

I "think" that XHTML does not define an 'unicode-bidi' attribute.
Do you mean, for 'unicode-bidi', "as defined in CSS 2.1"?
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: Atom license link last call

[Bjoern Hoehrmann]

* James M Snell wrote:
>Another concern that was raised to me by a colleague is that the license
>resource being pointed to could change over time, meaning that the
>license being referenced today may not be the same license being used
>tomorrow even tho URIs may be exactly the same.  If the license is
>controlled by a different entity than the publisher of the entry, this
>could cause problems.

Yeah, it would be good to have some of these things mentioned in the
draft, if only to encourage people to let a lawyer review tools they
may build upon this new link relation.

>Unfortunately, there is no language in RFC4287 I can draw upon here.

Okay, I guess this should be looked at when RFC 4287 is revised.

>Yes, this should be clarified.  Feed level licenses cover the metadata
>of the feed (title, subtitle, etc).  I've actually found very little use
>for feed level licenses and would actually be quite happy to remove them
>from the spec completely.

I think removing it would be better, yeah.

>> I think the concept of "informational content" used to explain some
>> of these things is too unclear to me to answer these questions.
>> 
>Ok

I hope you can come up with a better term and/or explain this better
in the draft, as I'd have similar difficulties for entries.

>> I think the reference to "copyright licenses" is a bit unfortunate.
>> Why is this reference to "copyright" necessary?
>
>Can you suggest a better term?

Just "licenses"?
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: Atom license link last call

[Bjoern Hoehrmann]

* James M Snell wrote:
>http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-license-06.txt

I do not understand section 4, it says the security considerations of
RFC 4287 apply; the only consideration there that could apply is that
IRIs are used, and as such considerations of RFC 3987 apply. The actual
registration then says there are no security considerations for the
new link relation. I think both sections should say the same, and if
security is truly irrelevant to the link relation, it should say that.
Perhaps you might to say something like, when used in Atom documents,
the security considerations for handling links in Atom documents apply.

I would personally like to see some note that implementations cannot
necessarily trust that the publisher has the right to license material
claimed to be covered by the license, and that care should be taken
when making decisions based on the license reference, such as
republishing the content.

The third paragraph in section 3 seems overly verbose to me, is there
no terminology introduced in RFC 4287 that could be used and/or re-
ferenced instead of the verbose discussion? Or is this assumed to be
the case already, and the "Implementors should note" non-normative
note just re-states what is stated elsewhere in the draft or the Atom
specification?

I do not quite understand feed-level licenses, the draft just says
what they don't cover, not what they do cover. Say I make a feed with
the five most insightful blog postings on international politics and
I license the feed under the most permissive license possible. Can
you then copy my list of entries over to your top five list? Just the
IRIs, or also the summary I wrote for those entries? What if I copied
the summary over from the original feed (assuming, e.g., I may copy
those, but you may not, for some twisted legal reason)? If I relate
the license to the entries, would the license cover my summary and
the third party entries, or just my summary, or just the content of
the third party entry? Should atom:source be used in such scenarios
specifically for license reasons?

I think the concept of "informational content" used to explain some
of these things is too unclear to me to answer these questions.

I think the reference to "copyright licenses" is a bit unfortunate.
Why is this reference to "copyright" necessary?
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: Datatype for IRIs in RELAX NG

[Bjoern Hoehrmann]

* Martin Duerst wrote:
>At 02:30 06/03/20, Bjoern Hoehrmann wrote:
>
> >In Schema 1.1 it is not possible for a xsd:string to be no xsd:anyURI.
>
>Can you explain? It seems you are saying that all xsd:strings are
>also xsd:anyURIs, but that seems going a bit too far.

Yes, that's exactly what the XML Schema 1.1 Last Call Working Draft
implies as far as I can tell.
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: Datatype for IRIs in RELAX NG

[Bjoern Hoehrmann]

* Elliotte Harold wrote:
>I would recommend against using xsd:anyURI for IRIs. A URI is much more 
>restrictive than an IRI, and one of the easiest things for a schema 
>validator to check about an xsd:anyURI is that it only contains 
>URI-legal ASCII characters. I think a new type is necessary if you do 
>want to allow IRIs instead of simple URIs. I suspect you could do it 
>with a regular expression but the syntax would be really hairy.

In Schema 1.1 it is not possible for a xsd:string to be no xsd:anyURI.
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: Atom syndication schema

[Bjoern Hoehrmann]

* Martin Duerst wrote:
>When looking with a microscope, you will find some little
>differences, because xs:anyURI was described before the IRI
>spec (RFC 3987) was approved. These differences are:
>
>1) xs:aryURI also allows spaces and a few other ASCII characters
>that are not allowed in URIs nor in IRIs (but the IRI spec has
>an escape hatch for such cases).
>2) The IRI spec contains many more details than the xs:anyURI
>description, in particular also some requirements re.
>normalization. However, some of the requirements in this
>area of the IRI spec may be lowered or removed in the future
>because we have received feedback from implementers that
>there are difficulties to implement these.

I agree with Martin that it would be incorrect to use xsd:anyURI here.
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: If you want "Fat Pings" just use Atom!

[Bjoern Hoehrmann]

* Graham wrote:
>"the XML processor must report the error to the application and that the
>processor is not required by the XML specification to continue
>processing; doing so is however an optional feature and further
>processing would be implementation-defined"
>
>vs
>
>"Once a fatal error is detected, however, the processor must not  
>continue normal processing (i.e., it must not continue to pass  
>character data and information about the document's logical structure  
>to the application in the normal way)."

Yes, the normal way could be for example to have the illformed flag on
each event not set, and an unnormal way would be to have the flag set.
In particular, "the processor MAY make unprocessed data from the
document (with intermingled character data and markup) available to
the application" and there is no constraint on what the application
may or must not do with such data.
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: If you want "Fat Pings" just use Atom!

[Bjoern Hoehrmann]

* Tim Bray wrote:
>> That's a bit misleading, a fatal error just means that the XML
>> processor must report the error to the application and that the
>> processor is not required by the XML specification to continue
>> processing; doing so is however an optional feature and further
>> processing would be implementation-defined. So this scenario is
>> unconstrained by the XML specifications.
>
>No.  See, http://www.w3.org/TR/REC-xml/#sec-terminology, under "fatal  
>error". -Tim

Yes, exactly what I wrote...
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: If you want "Fat Pings" just use Atom!

[Bjoern Hoehrmann]

* Tim Bray wrote:
>If you encounter a busted tag on the Nth entry, per the XML spec  
>that's a fatal error and you can't process any more.

That's a bit misleading, a fatal error just means that the XML
processor must report the error to the application and that the
processor is not required by the XML specification to continue
processing; doing so is however an optional feature and further
processing would be implementation-defined. So this scenario is
unconstrained by the XML specifications.
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: Where's the Registry of Link Relations?

[Bjoern Hoehrmann]

* Robert Sayre wrote:
>Anyone seen it or know where it will be found?

The IANA registry? It will be created some time between now and the
publication of the RFC. Same goes for the Atom media type and any
other pending IANA actions.
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: xml:base abuse

[Bjoern Hoehrmann]

* Sjoerd Visscher wrote:
>It would be really cool if you would move the xml:base of the entry to 
>the div, but as you have 2 divs per entry I can imagine you don't want 
>to do that. Or you could change the base URI to f.e. 
>When/200x/2005/08/14/Java-Net-Terms.atom (even if that doesn't 
>dereference to anything)

xml:base is not allowed on xhtml1:div elements.
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: xml:base abuse

[Bjoern Hoehrmann]

* Sjoerd Visscher wrote:
>A while ago we had a discussion about how xml:base should be used.
>We didn't reach a conclusion, but I think we need to act.

How to use xml:base is a matter of the xml:base specification
and (less so) the resource identifier specifications. If you
think xml:base is unclear in this regard, please let the W3C
XML Core Working Group know.

>Now I think that no matter what we decide, we should not do
>something that the writer of the URI spec thinks is an abuse.

"We" as in there is specific text in one of the atompub drafts
that make misleading suggestions that are inconsistent with
the xml:base Recommendation or RFC 3986/7 other than some con-
fusion about how to handle IRIs in non-Unicode encoded Atom
documents that are not in NFC?
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: spec bug: can we fix for draft-11?

[Bjoern Hoehrmann]

* Paul Hoffman wrote:
>You can't compare an IRI with a non-IRI. So, if you are handed an 
>non-IRI (as in, an IRI-looking string that has whitespace around it), 
>should you fail immediately or try harder? I propose trying harder, 
>but I am open to "just fail".

Well, if we expect that many content providers will consider the content
model of atom:id elements to be "IRI with optional surrounding white
space" then we define the content model accordingly. Hardcoding "We know
many people will ignore this, but the content model is 'IRI *without*
optional sourrounding white space'" doesn't make any sense.

Of course, content providers would pay more attention to the requirement
if Atom implementations must not (and in practise will not) provide the
content of feeds or entries with such a non-conforming atom:id to users,
so that might indeed be an option too, though I'm not sure how likely it
is that implementers follow such a requirement.
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: spec bug: can we fix for draft-11?

[Bjoern Hoehrmann]

* Tim Bray wrote:
>"Implementors are advised that there is a common class of error in  
>[...]

Sorry but this is ridiculous; if we say X MUST Y even though we know
that many X won't Y we are abusing RFC 2119 terminology and make it
much more difficult to evangelize 100% compliance, since this allows
people to argue that compliance with this particular requirement is
not relevant in practise so they can worry less about compliance in
general.
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: spec bug: can we fix for draft-11?

[Bjoern Hoehrmann]

* Dave Pawson wrote:
>> > Even if we decide that whitespace is not significant, I do believe that
>> > having the feedvalidator issue a warning in such cases is appropriate.
>> 
>> +1
>
>What is the IETF version of an errata sheet? Is that the right
>place to tackle this?

For RFCs see .
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: Atom 1.0 xml:base/URI funnies

[Bjoern Hoehrmann]

* Graham wrote:
>It seems pretty clear to me that whoever wrote the same-document  
>references section simply wasn't thinking about embedded base URIs,  
>and thus it can be safely ignored.

Read e.g. .
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: Atom 1.0 xml:base/URI funnies

[Bjoern Hoehrmann]

* Sjoerd Visscher wrote:
>And that's why you can't use it as a reference to your site.

That depends a bit on same-document reference processing of Atom
processors. If the Atom processor assumes the link refers to some
web site and passes the absolute reference to some other user agent
there would not be a problem. If however e.g. FireFox implements
some Atom rendering and makes the link available to the user, it
might indeed consider the link to point to the same document and
not navigate to the web site. If that's a concern, Tim cannot use
http://www.tbray.org/ongoing/ as Base URI. That would of course
make using xml:base a bit difficult in practise...
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: Evangelism, etc.

[Bjoern Hoehrmann]

* A. Pagaltzis wrote:
>I like both versions for different reasons. Thanks, of course,
>for providing a HTML rendition – I, too, have to say I find the
>ASCII versions very 1989. (I use rfc.net to read RFCs so there is
>at least a modicum of formatting and actual, you know, links.)

There is http://www.apps.ietf.org/rfc/ of course...
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

"White-space"

[Bjoern Hoehrmann]

Hi,

  http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-10.txt
refers to "white-space" a couple of times but does not define this term.
The exact definition is important to know for 4.1.3.3 item 6 and I would
like to avoid to /assume/ that this means any number of U+0020, U+0009,
U+000D, U+000A characters.

regards,
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: The Atomic age

[Bjoern Hoehrmann]

* Dan Brickley wrote:
>http://www.w3.org/2001/sw/BestPractices/HTML/samples/atom/a1.xml

`Content-Type: text/xml; qs=0.9`. Hurray...
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: The Atom namespace, etc.

[Bjoern Hoehrmann]

* Paul Hoffman wrote:
>This is rarely done in RFCs. Further, Section 5 is clearly listed in 
>the table of contents, and someone who intends to implement the 
>protocol probably has at least skimmed the document before they read 
>the details in the Security Considerations section.

Well, I think the lack of detail in 8.5 is confusing and adding a "(see
section 5)" in auth48 would improve the legibility of the document; such
cross-references are not uncommon in long RFCs either, but I do not feel
strongly about this.
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Section 8 should refer to 5

[Bjoern Hoehrmann]

Hi,

  I think it would be helpful if section 8 ("Security Considerations")
of the latest draft includes a reference to section 5 "Securing Atom
Documents".

regards,
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

The Atom namespace

[Bjoern Hoehrmann]

Hi,

  http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-10.txt
defines "http://www.w3.org/2005/Atom"; as namespace for the Atom format.
Is this really a good choice considering that most of the similar W3C
namespaces use different casing, e.g.

  http://www.w3.org/1999/xhtml 
  http://www.w3.org/1999/xlink 
  http://www.w3.org/2000/svg 
  http://www.w3.org/2001/vxml 
  http://www.w3.org/2001/xml-events 
  http://www.w3.org/2002/xforms 
  http://www.w3.org/2004/xbl
  ...

Though I guess it's to late now to change this...
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: RNG validators capable of fully using the Atom schema?

[Bjoern Hoehrmann]

* Henri Sivonen wrote:
>I'm wondering which validator was used for testing the Atom 
>RNG+Schematron schema. Which validators support Compact Syntax with 
>embedded Schematron? I am particularly interested in Java solutions.

http://www.topologi.com/products/validator/ is said to support it.
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: What is a media type?

[Bjoern Hoehrmann]

* David Powell wrote:
>I'm asking this because I really don't know whether parameters are
>supposed to be allowed in the "type" attribute or not.

http://www.imc.org/atom-syntax/mail-archive/msg08283.html
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: AD Review Comments and Questions: draft-ietf-atompub-format-07

[Bjoern Hoehrmann]

* Tim Bray wrote:
>Our plan, as we discussed with you & Ted. last year, is to use a W3C 
>namespace.  The current value is a placeholder.  Should we note this in 
>-08?

Do you have a pointer to this?

>> [draft-freed-media-type-reg]
>
>Rob/Mark?

(Note that this is also a matter of reviewing the draft
and checking that we took all differences into account).

>> The MIME media type registration template included in section 7 MUST be
>> submitted to the ietf-types list ([EMAIL PROTECTED]) for 
>> review.

>Scott, what's the scheduling on that?  Do we launch that right now, 
>independent of the rest of the document review process?

We should announce this to [EMAIL PROTECTED] aswell.
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: application/rss+xml

[Bjoern Hoehrmann]

* Tim Bray wrote:
>On Mar 29, 2005, at 7:37 PM, Randy Charles Morin wrote:
>> k, let's start by admitting my true goal is to get application/rss+xml
>> into the registered IANA media types [1].
>
>Uh, I think we can register it as a side-effect of getting the format 
>draft through the process with an RFC number. Right, Paul? -Tim

IESG approval of an Internet-Draft with a media type registration would
register the type, yes. Whether we should try to register application/
rss+xml is a different question though.
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: s/url/web/

[Bjoern Hoehrmann]

* Robert Sayre wrote:
>For "web":
>Bray, Sayre, Duerst, Brickley
>
>For "iri":
>de hÓra, Höhrmann
>
>For "uri":
>Gregorio, van Kesteren

"resource", "ref", "about", etc. work for me, but not any of those.
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: s/url/web/

[Bjoern Hoehrmann]

* Dan Brickley wrote:
>The definition says, in effect, "The Web is an information space in 
>which we use URIs when identifying things". It does not rule out 
>other, complementary, identification mechanisms, nor does it equate the 
>Web with any specific set of entities.

Right, nor does it say that an item of interest identified by a "Uniform
Resource Identifier" is in this information space. People not familiar
with IRIs do not consider items of interest on their local hard drive
identified by a file:/// URL items in the information space "web" and
would consequently think that using file:///
is improper use of the element. That's not the case, so we have

   -- wrong
   -- unknown to many users
   -- misleading to many users

I suggest confronting users with something unknown is better than
misleading them.
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: s/url/web/

[Bjoern Hoehrmann]

* Dan Brickley wrote:
>> I think the question is which of these is meant by "the web":

>I encourage Atom to follow the WebArch REC, let's call it (d),
>http://www.w3.org/TR/webarch/#intro
>[[
>The World Wide Web (WWW, or simply Web) is an information space in which
>the items of interest, referred to as resources, are identified by
>global identifiers called Uniform Resource Identifiers (URI).
>]]

Let's ignore that not all IRIs are URIs and let's assume that this is a
definition of "Web", are you saying that this definition is equivalent
to 'the set of all URIs is the information space "Web"'? If those are
not equivalent I am not sure what you are suggesting here.
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: s/url/web/

[Bjoern Hoehrmann]

* Dan Brickley wrote:
>Maybe I misread your intent, in that case. You objected strongly
>("certainly not...") without giving any supporting reason. Could
>you elaborate on the reasoning behind your objection to "web"?

"To specify the author of an entry use the author element. You can then
use the name child element to specify the name of the author, the email
child element to specify the email of the author, and the web child
element to specify the web of the author." That's crazy Frontpage-speak.
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: s/url/web/

[Bjoern Hoehrmann]

* Dan Brickley wrote:
>> >In both cases they're not actually URIs, they're IRIs, so the name is 
>> >WRONG, except for nobody knows what an IRI is so renaming them "iri" 
>> >would be confusing, and anyhow everyone thinks of URLs not *RIs, but 
>> >naming them "url" would be wrong too, so why don't we actually change 
>> >them to say what they're there for not what their syntax is and use 
>> >"web" in both cases?  -Tim
>> 
>> We can call those "at" or "about" or "internet" but certainly not "web".
>
>While we're at it, we can relive 10-15 years of URN vs URI debates on the 
>Atom list instead of shipping product. Are you appealing to some notion of 
>'online' versus 'offline' resource? A spec could be cited from the formal 
>Atom spec? Such distinctions are notoriously hard to maintain... If you
>want to add an implicit (and imho illadviced) notion of
>'URI dereferencability' into the spec, it'd be good to see candidate
>text for inclusion, rather than doing it via attribute/element name 
>choice. Note that the deferencability of identifiers changes over time, 
>as infrastructure is deployed (or rots away); eg. DOIs, gopher:, java: URIs...

I do not really understand what you are trying to ask or say here. I
suppose you object to call those elements and attributes anything but
"web" for some reason or you object to the alternate names I suggested.
In case of the latter you seem to somehow think that at/about/internet
suggests what you call "dereferencability" while "web" does not. That
would not make much sense to me, so I fail to get your point.
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: s/url/web/

[Bjoern Hoehrmann]

* Tim Bray wrote:
>There are a couple of places where we use "uri" in the markup, 
>specifically the "atom:uri" element (3.2.2) and the "uri" attribute of 
>"atom:generator" (4.2.5).
>
>In both cases they're not actually URIs, they're IRIs, so the name is 
>WRONG, except for nobody knows what an IRI is so renaming them "iri" 
>would be confusing, and anyhow everyone thinks of URLs not *RIs, but 
>naming them "url" would be wrong too, so why don't we actually change 
>them to say what they're there for not what their syntax is and use 
>"web" in both cases?  -Tim

We can call those "at" or "about" or "internet" but certainly not "web".
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: xsd:dateTime vs. RFC 3339

[Bjoern Hoehrmann]

* Tim Bray wrote:
>I tend to agree as well; in this case, the fact that this is an XML 
>vocabulary is probably more relevant than the fact that it's an IETF 
>RFC.  So can we please have a Pace to call out to XSD?  I'm pretty sure 
>that implementors would just use the libraries and The Right Thing 
>Would Happen. -Tim

That depends on whether we include restrictions that such libraries
would ignore...
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: Call for final Paces for consideration: deadline imminent

[Bjoern Hoehrmann]

* Paul Hoffman wrote:
>>  Although I can't find it specified in the current draft, there used
>>to be a rule that you weren't supposed to use the same atom:id more than
>>once in a single feed.
>
>The current draft says:
>
>5.8  "atom:id" Element
>
>The "atom:id" element is an Identity construct that conveys a
>permanent, universally unique identifier for an entry.  atom:entry
>elements MUST contain exactly one atom:id element.
>
>That means that you're not allowed to sue the same atom:id in any two 
>entries, ever.

It does not mean that once cannot have multiple versions of the same
entry in a feed (or duplicate entries for that matter).
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: Posted PaceTextRules

[Bjoern Hoehrmann]

* Martin Duerst wrote:
> >> http://www.w3.org/MarkUp/2004/xhtml-faq#xmlspace cites a quite different
> >> opinion on this matter...
> >
> >Yes, well that opinion is (a) specific to HTML and (b) wrong.  I'm amazed 
> >that the W3C allowed that to be published.  -Tim
>
>Would you mind explaining why you think it's wrong?

Such white-space is considered character data in XML 1.0 and DOM Level 3
defines

  The Text interface inherits from CharacterData and represents the
  textual content (termed character data in XML) of an Element or Attr.
  If there is no markup inside an element's content, the text is
  contained in a single object implementing the Text interface that is
  the only child of the element. If there is markup, it is parsed into
  the information items (elements, comments, etc.) and Text nodes that
  form the list of children of the element.

which refers to the XML Infoset which requires that such white-space is
exposed. There is thus no reasonable ground to claim that xml:space has
any impact whatsoever on the document object model; the FAQ claims the
exact opposite, in particular, without ever saying what white-space
would be in the DOM for e.g.

  x  y

It could be "x y" or "xy" or for

  x
y

it could be "xy", or "x y", etc. Following the cited rationale in the
FAQ, all XML formats that do not define xml:space='preserve' for all
elements would have essentially random white-space processing behavior,
which is fortunately not the case. Please refer to

  
http://hades.mn.aptest.com/cgi-bin/voyager-issues/Modularization-DTDs?id=6300#followup2

for further details.
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: URI canonicalization

[Bjoern Hoehrmann]

* Roy T. Fielding wrote:
>It is not necessary for the format to require world peace, or
>anything generally equivalent to it.  Give implementations the
>freedom to do whatever they like with the format -- just tell
>them what the syntax means and the implementations will sort
>themselves out.

YMMD.
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: atom:info [was Re: Comments on format-05]

[Bjoern Hoehrmann]

* Robert Sayre wrote:
>If I tell NetNewsWire to GET something in the subscribe dialog, my 
>dispatching instructions are clear. Everything is a feed. Making up 
>rules for application/xml, text/xml, and application/octet-stream will 
>require superceding some RFCs that I'd rather not mess with.

What makes you think that "everything is a feed" might be consistent
with these RFCs?
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: Posted PaceTextRules

[Bjoern Hoehrmann]

* Tim Bray wrote:
>Currently, the draft says *nothing* about xml:space (unless I'm 
>mis-using the search function).  If you read the specification for 
>xml:space (http://www.w3.org/TR/REC-xml/#sec-white-space), all it says 
>is that this is a message from the author to downstream software.  So 
>there is nothing anywhere that says anything normative about xml:space.

http://www.w3.org/MarkUp/2004/xhtml-faq#xmlspace cites a quite different
opinion on this matter...

>Is the point here to tell them that if they want to control the 
>formatting, they should damn well use type="HTML" or "XHTML"?  If so, 
>maybe we should spin the language around and say that:
>
>  When type="TEXT", receiving software has a great deal of freedom in
>  how it chooses to display the content.  Thus, publishers who want
>  to exercise formatting control should use the values "HTML" or
>  "XHTML" for the type attribute

It would seem authors expect that

  ...

gets rendered as if it were

  
...
  

What's the point of allowing such random results?
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: URI canonicalization

[Bjoern Hoehrmann]

* Robert Sayre wrote:
>Suppose your user is subscribed to a feed containing 1000 entries. One 
>day, the host name is no longer capitalized. Are you going to put 1000 
>new, duplicate entries in front of the user?

It seems the Working Group is split on the requirements for duplicate
detection, we have participants who want to require a deterministic
algorithm to gurantee interoperable detection, participants who want
implementation-defined algorithms to implement best-effort strategies,
and participants who want to encourage interoperable detection while
allowing implementation-defined algorithms for various reasons. Maybe
we should first find some form of consensus on the requirements before
we proceed with writing new or removing old specification text.

I do not think it will contribute to Atom's success if some Atom im-
plementations are better than other implementations when it comes to
duplicate detection.
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: PaceFormatSecurity

[Bjoern Hoehrmann]

* Dan Brickley wrote:
>> Considering the large amount of (X)HTML that are being syndicated via RSS  
>> and Atom today and will be in the future, I think we should. (X)HTML will  
>> be the main markup used inside all Atom Text Constructs, and while MathML,  
>> SVG and other markup languages we don't know about may contain security  
>> issues, they aren't nearly as important to mention as those that lie  
>> within (X)HTML.
>
>As far as SVG goes, I suspect a lot of the issues will be around
>Javascript, just as in (X)HTML.

If people think http://www.w3.org/TR/2004/WD-SVG12-20041027/mimereg.html
is insufficient in this regard, now would be a good time for comments on
the document. If there are a lot of issues around scripting, I should
point out that it is essentially unreasonable to expect security con-
siderations for a script media type to say much more than that it is
exceedingly dangerous for a receiving user agent to execute such content
in an uncontrolled manner.
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: PaceFormatSecurity

[Bjoern Hoehrmann]

* Tim Bray wrote:
>At this point we should appeal to our designated IETF culture/process 
>experts; Scott/Ted/Paul, any guidance?

http://www.ietf.org/rfc/rfc3552.txt
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: Difference of TEXT and XHTML?

[Bjoern Hoehrmann]

* Antone Roundy wrote:
>1) Clearly, this cannot appear in an Atom feed, because © is not 
>an XML entity:
>
>   ©
>
>What about this?
>
>   xmlns="http://www.w3.org/1999/xhtml";>©

That depends on whether the document has a document type declaration and
if how it looks like. And on various properties of the XML processor and
the application using it, as well as on various dynamic conditions. E.g.
whether the document type declaration refers to an external subset and
whether the processor attempts to resolve the reference. If there is no
document type declaration, the document would not be well-formed.

>2) If that is valid (I'm presuming that it is, and that it should be 
>rendered as a copyright symbol), I'm wondering how many XML parsers are 
>going to choke on it anyway.  If that is NOT valid, then how would one 
>put a copyright symbol (or any other XHTML entity that is not an XML 
>entity) into XHTML content in an Atom feed?

There are two ways to refer to such characters, either by literally in-
cluding them (in very much the same way as you've included "X" and "L"
in your example) or by using character references ala

  mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: PaceMustBeWellFormed status

[Bjoern Hoehrmann]

* Tim Bray wrote:
>If there were no further discussion:  The WG completely failed to 
>converge to consensus on these issues last time around. Consensus can 
>still be found here. -Tim

I would suggests we contact implementers and ask them whether they will
conform to these requirements or not. If we are not convinced that they
will implement the spec as written, I consider the requirements point-
less and misleading.

How do we expect to manage updates to RFC3023 with/without this Pace?
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: PaceMustBeWellFormed status

[Bjoern Hoehrmann]

* Tim Bray wrote:
>On Jan 24, 2005, at 5:12 PM, Joe Gregorio wrote:
>> It's good work but it belongs in a primer or best practices document.
>
>+1.  I like it, I'd like to use it somewhere, but I don't think it 
>belongs in the core spec. -Tim

I am afraid, if requirements ala "clients MUST stop processing at the
first well-formedness error" are not in the "core spec", implementers
might miss them, in fact, I would argue that the requirement does not
apply if it is not part of the conformance requirements for Atom format
implementations.
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: PaceMustBeWellFormed status

[Bjoern Hoehrmann]

* Robert Sayre wrote:
>I'm very -1 on this, since it makes the definition of the Atom format an 
>HTTP message, rather than an XML document.

It seems common practise to include requirements for implementations of
a format into the specification of the format. Why should these be kept
separate? In fact, I see a number of statements ala "Processors MUST" in
the current draft. Do you mean these should be removed?
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: PaceIRI status

[Bjoern Hoehrmann]

* Julian Reschke wrote:
>>>The big difference here is that XMLNS uses IRIs/URIs as identifiers and 
>>>only for that. However, what is an XSLT that transforms Atom content to 
>>>HTML supposed to do when it encounters a IRI which isn't a legal URI? 
>> 
>> http://www.w3.org/TR/xslt#section-HTML-Output-Method
>> 
>>   The html output method should escape non-ASCII characters in URI
>>   attribute values using the method recommended in Section B.2.1 of
>>   the HTML 4.0 Recommendation.
>
>How does that help with IDNs?

After applying the algorithm, how is the situation different from
the current draft-ietf-atompub-format-04.txt draft which refers to
RFC2396bis?
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: PaceIRI status

[Bjoern Hoehrmann]

* Julian Reschke wrote:
>The big difference here is that XMLNS uses IRIs/URIs as identifiers and 
>only for that. However, what is an XSLT that transforms Atom content to 
>HTML supposed to do when it encounters a IRI which isn't a legal URI? 

http://www.w3.org/TR/xslt#section-HTML-Output-Method

  The html output method should escape non-ASCII characters in URI
  attribute values using the method recommended in Section B.2.1 of
  the HTML 4.0 Recommendation.
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: PaceAttributesNamespace (was Re: AtomAsRDF_PaceAttributesNS)

[Bjoern Hoehrmann]

* Danny Ayers wrote:
>Again, I don't think this a problem when the
>no-namespace/atom-namespace mapping is only an option for consumers -
>unless I'm missing something?

I am not sure what you consider a "consumer" in this context, pointer?
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: PaceAttributesNamespace (was Re: AtomAsRDF_PaceAttributesNS)

[Bjoern Hoehrmann]

* Danny Ayers wrote:
>> This does not make much sense to me, it is either not possible to write
>> a test case for the first requirement in which case this would be an im-
>> plementation detail which is out of scope of the specification, or it is
>> possible to write such a test case in which case this would render Atom
>> inconsistent with a broad range of XML technologies, e.g., for
>> 
>>   
>
>Sorry, swap in the word 'consumer'. Straight XML applications will see
>that exactly as written, languages that require disambiguation of 
>'bar' will read it as 'atom:bar'
>
>A test case would be an RDF processor seeing the triples:
>
>_:fooinstance rdf:type atom:foo .
>_:fooinstance atom:bar "baz" .
>
>(assuming atom:foo was a class)

If this implementation detail is exposed to the user, it would seem
reasonable to consider such a software a Atom-to-something-else con-
verter; you would thus seem to propose the introduction of conformance
requirements for Atom conversion programs into the specification. No?
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: PaceSimpleLanguageTagging status

[Bjoern Hoehrmann]

* Martin Duerst wrote:
> >> Not yet taken up by the WG, depends on the discussion that comes with 
>this call. Same rules as all the others: there has to be a positive WG 
>consensus that each adds to the base specification.  -Tim
> >
> >+1, at least for atom:language inside the header. For elements, well, 
>there _are_ use cases for elements in different languages, so, since it is 
>optional, +1 again.
>
>-1, or better, -2. Inventing things like atom:language when there
>is xml:lang is just completely useless and superfluous.

Could you clarify how xml:lang solves the problems stated in the Pace?
The alternatives to the Pace would seem to be either restrict xml:lang
to specific elements or implementations that lose xml:lang information
or, in an authoring scenario, do not allow to use it -- i.e., ignoring
the problem in the specification. Neither of which is really helped by
xml:lang, so your comment seems a bit weird.
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: PaceAttributesNamespace (was Re: AtomAsRDF_PaceAttributesNS)

[Bjoern Hoehrmann]

* Sam Ruby wrote:
>I'm a bit concerned about precedence rules (what happens if there is an 
>href attribute *AND* an atom:href attribute?).  What makes most sense 
>here is for a prohibition disallowing such in any exension.  I would 
>support such a rule.

Allowing either atom:href or href is not a good idea either, you have to
check for both attributes each time you access it and if having both at
the same time is not allowed or causes undefined behavior, you need to
avoid that, turning

  x.setAttributeNS(null, 'foo', 'bar');

into

   if (x.hasAttributeNS(null, 'foo') &&
   x.hasAttributeNS(atom, 'foo'))
   {
  throw "...";
   }
   else
   {
   x.removeAttributeNS(atom, 'atom');
   x.setAttributeNS(null, 'foo', 'bar');
   }

This might not be too relevant for some Atom implementations, but if you
implement Atom through SVG 1.2 + sXBL + ECMAScript, the result would not
be pretty.
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: PaceAttributesNamespace (was Re: AtomAsRDF_PaceAttributesNS)

[Bjoern Hoehrmann]

* Danny Ayers wrote:
>To be inserted: 
>{{{
>Section 2.  Atom Documents
>
>Atom processors MAY interpret unprefixed attribute names as their
>namespace-qualified equivalents.
>If they do, then all Atom attribute names MUST appear in the Atom namespace.
>
>}}}

This does not make much sense to me, it is either not possible to write
a test case for the first requirement in which case this would be an im-
plementation detail which is out of scope of the specification, or it is
possible to write such a test case in which case this would render Atom
inconsistent with a broad range of XML technologies, e.g., for

  

an XPath expression

  *[namespace-uri() = $x)]/@*[namespace-uri() = $x]

where $x is the Atom namespace URI would be allowed to match. I am -1 on
any proposal that allows or requires to put Atom-defined attributes on
Atom elements in any namespace or process Atom documents as if they were
constructed like that if you can tell the difference.
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: PaceAttributesNamespace (was Re: AtomAsRDF_PaceAttributesNS)

[Bjoern Hoehrmann]

* Antone Roundy wrote:
>BTW, am I remembering correctly that "xml:" in "xml:lang" and 
>"xml:base" isn't a namespace prefix? You don't see xmlns:xml="..."--so 
>is "xml:" not a namespace prefix, or does it just not have to be 
>declared?  If it IS a namespace prefix, then the above language works 
>only if you don't consider publishing "xml:base" and "xml:lang" to be 
>ADDING the prefix, since it was already there in the spec, but it may 
>be possible to word it better.

:

[...]
  The prefix xml is by definition bound to the namespace name
  http://www.w3.org/XML/1998/namespace. It may, but need not,
  be declared, and must not be bound to any other namespace
  name. No other prefix may be bound to this namespace name. 
[...]
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: Work Queue Rotation #13

[Bjoern Hoehrmann]

* Antone Roundy wrote:
>The difference is that we (at least some of us) don't want atom:link 
>used for things like this:
>
>
>
>We want it used only for links that are meant to be activated by the 
>user and result in visiting the resource.

I don't think the HTML 4.01 Recommendations considers this "link"
activated when the style sheet is applied to the document, though
the question is quite interesting.

Re: Work Queue Rotation #13

[Bjoern Hoehrmann]

* Martin Duerst wrote:
>"makes no sense" isn't a technical argument. "it doesn't work" or
>"here is something better" is much better. I think Roy has expressed
>the reasons for this proposal best, but I'll summarise them here:
>
>- central registry for well-used stuff so that it can be found, and
>   doesn't need to be duplicated, and can be expressed in a short form
>- Ability for a very wide range of people to create their own values
>   ad-hoc if they need them, without collision (as long as the rules are
>   followed)

When Tim asked not to discuss syntax and rather how to proceed and Roy
proposed this syntax, Tim already mentioned using URIs for extensions
here, so this is nothing new or unique to Roy's proposal.

>- Overall common space for these values, and clear mapping to technologies
>   such as RDF.

That does not seem worth the additional complexity, we do not map other
attribute values into "URI space" either, so why would we do this here?

Re: Work Queue Rotation #13

[Bjoern Hoehrmann]

* Tim Bray wrote:
>PaceLinkPurpose, which is closed, wants to replace the description of 
>the language describing .  There's a proposal from Rob Sayre to 
>replace it, at http://imc.org/atom-syntax/mail-archive/msg11584.html - 
>that proposal got some cheers and no significant pushback; I'm inclined 
>to skip over the Pace process and declare Sayre's proposal to have 
>rough consensus.  If anyone disagrees, Rob has to write a Pace.

The proposal makes little sense to me, in particular I do not understand
the difference to "HTML dialects" that is suggested here, so I am -1 to
have this text in the draft.

>PaceFieldingLinks:
>* Some positive comments, no -1's

I am clearly -1 on this as I've indicated earlier as this base URI stuff
makes no sense.

>* Outstanding calls for language about how rel= values are to be 
>compared.  A Pace needs to be written if someone cares enough

Sorry but the Pace is clearly incomplete without this.