Re: PaceLangSpecific

2005-02-08 Thread David Powell


Tuesday, February 8, 2005, 12:44:26 AM, you wrote:

 PaceLangSpecific

 +1, but also needed for atom:generator

 hmmm ... if we have xml:lang on content, we are going to also need
 @hreflang for content src=... /, because while some types of referenced
 content can have the language attached, at type=text/plain cannot.

text/plain can have a Content-Language header though - is that compatible with
xml:lang?

-- 
Dave



Re: PaceStopArguingAboutSlidingWindowsAndCurrentStateEnoughAlready

2005-02-08 Thread Bill de hÓra
Henry Story wrote:
If you just want to stick to syntax, then please leave the pace
as it is. Don't try to impose a model through syntax and then
argue that people can't argue about the model that you are
surreptitiously trying to introduce.
Henry, I have no idea what you are talking about.
cheers
Bill


Re: PaceXhtmlNamespaceDiv

2005-02-08 Thread Henri Sivonen
On Feb 7, 2005, at 23:21, Sam Ruby wrote:
  1) Graham (who uses proper XML tools) will have to do more work.
Which tools? How much more? One loop more?
(FWIW, I do not consider Apple's Core Foundation XML parser a proper 
XML tool.)

  2) Tim (who uses string concatenation) will have to do more work.
When I did a string concatenation implementation, using colonified 
names was not a big deal.

  5) For some combinations of clients and servers, entries produced
 via an HTTP POST will end up with multiple divs.
I can anticipate that happening either way.
--
Henri Sivonen
[EMAIL PROTECTED]
http://iki.fi/hsivonen/


Re: PaceXhtmlNamespaceDiv

2005-02-08 Thread Henri Sivonen
On Feb 8, 2005, at 07:03, Henri Sivonen wrote:
On Feb 8, 2005, at 01:55, Sam Ruby wrote:
Can I get one of you three to mock up what Tim's feed should look 
like?
a:feed xmlns:a='http://purl.org/atom/ns#draft-ietf-atompub-format-04' 
version='draft-ietf-atompub-format-04 : do not deploy' 
xmlns='http://www.w3.org/1999/xhtml' xml:lang='en-us'
...
 a:entry
...
  a:content type='XHTML'I was in the drugstore picking up a 
prescription and wandered into the computer section, where I found 
myself impulse-buying a 
href='http://dvforge.com/themousebt.shtml'The Mouse BT/a from some 
outfit
...
OR (even less impact on string concatenators):
feed xmlns='http://purl.org/atom/ns#draft-ietf-atompub-format-04' 
version='draft-ietf-atompub-format-04 : do not deploy' 
xml:lang='en-us'
...
 entry
...
  a:content type='XHTML' 
xmlns:a='http://purl.org/atom/ns#draft-ietf-atompub-format-04' 
xmlns='http://www.w3.org/1999/xhtml'I was in the drugstore picking up 
a prescription and wandered into the computer section, where I found 
myself impulse-buying a href='http://dvforge.com/themousebt.shtml'The 
Mouse BT/a from some outfit
...

--
Henri Sivonen
[EMAIL PROTECTED]
http://iki.fi/hsivonen/


Re: PaceXhtmlNamespaceDiv

2005-02-08 Thread Henri Sivonen
On Feb 7, 2005, at 22:58, Sam Ruby wrote:
If you are opposed to this pace, then what div element?
If the pace does not get through, it is still permissible to put a div 
in there as part of the content. In fact, either way it is permissible 
to add meaningless extra divs, since a div can nest in a div.

--
Henri Sivonen
[EMAIL PROTECTED]
http://iki.fi/hsivonen/


Re: PaceStopArguingAboutSlidingWindowsAndCurrentStateEnoughAlready

2005-02-08 Thread Danny Ayers

On Tue, 08 Feb 2005 10:40:43 +, Bill de hÓra [EMAIL PROTECTED] wrote:
 
 Henry Story wrote:
  If you just want to stick to syntax, then please leave the pace
  as it is. Don't try to impose a model through syntax and then
  argue that people can't argue about the model that you are
  surreptitiously trying to introduce.
 
 Henry, I have no idea what you are talking about.

I think all Henry's referring to is the implicit model - only so much
is made explicit in the spec. There's the obvious containership
semantics of XML, there are also plenty of assumptions being made
about server/client architectures. Bits over the wire are useless on
their own, when semantics are to be attached to them there is benefit
in them being standardised through specs.

However even if there was the will to define a model, I can't see it
happening in the time frame for Atom 1.0. Getting something in an I-D
later for RDF-based interop should benefit the core, even without
tight spec coupling. But don't let's kid ourselves what we have right
now is much more than a syntax and a model with
ArchitectureByImplication [1].

10/10 for the Pace title, btw ;-)

Cheers,
Danny.

[1] http://c2.com/cgi/wiki?ArchitectureByImplication









-- 

http://dannyayers.com



Re: PaceLangSpecific

2005-02-08 Thread Henri Sivonen
On Feb 8, 2005, at 10:43, David Powell wrote:
text/plain can have a Content-Language header though - is that 
compatible with
xml:lang?
For practical purposes, yes. In theory, the semantics are different.
xml:lang specifies the language of the content but Content-Language 
describes the language of the intended audience.

--
Henri Sivonen
[EMAIL PROTECTED]
http://iki.fi/hsivonen/


Re: PaceProfile

2005-02-08 Thread Bill de hÓra
Robert Sayre wrote:
Bill de hÓra wrote:
The problem is that switching on the content of an element/attribute 
is Atom's get out of jail card wrt extensibility. It is the default 
Atom extensibility model, as it's the only game we have to play that 
doesn't involve screwing about with the meaning of existing core data 
items or adding new core items. Allowing people to add elements in 
other namespaces under atom:feed or atom:entry and calling that 
extensibility is like saying a new carpet in my living room is an 
extension to my house - it's a crashingly weak approach.

So, is that a +1 or a -1 on the profile concept?
[You mean we have to decide?!?. Now!?!]
+1 on the concept. I've seen enough cases in the last week to suggest 
it's useful.

-1 on @profile - use an @rel to hold the content instead. I'm not sure 
whether atom:feed should get an @rel or whether we should use 
atom:feed/atom:[EMAIL PROTECTED]

cheers
Bill



Re: PaceXhtmlNamespaceDiv

2005-02-08 Thread Julian Reschke
Sam Ruby wrote:
Bill de hÓra wrote:
Sam Ruby wrote:
If this Pace is not adopted, the following predictions can be made:
  1) Graham (who uses proper XML tools) will have to do more work.
I'd like to see a concrete example where this is a problem. As far as I 
can tell, the content construct itself can be considered the container, 
so whether or not a mandatory DIV element is present, there will always 
be a useable container element.

  2) Tim (who uses string concatenation) will have to do more work.
Nothing changes for Tim, he can continue to produce the output he's 
producing currently.

  3) More feeds will be harder to read (that's why I asked you to
 experiment with alternate serializations.
Whether something is easier to read seems to be a matter of taste: I 
certainly prefer a globally scoped XHTML namespace declaration, and no 
additional DIV elements.

  3) More feeds will be invalid (content in atom namespace)

Perhaps I misunderstand... but this shouldn't result in invalid Atom 
feeds ever - content areas should be able to hold any-namespace not 
any-namespace-atom-namespace. Worst case is mangled content when the 
content is lifted out using namespace aware tools. In other words, the 
container markup format is just dandy, but the content they carry is 
potentially trashed. If we condone default namespaces this is what we 
can expect to happen. We discussed warning people about this broken 
piece of XML technology last year and it was punted to an Implementors 
Guide - I'm somewhat unsympathetic now if we find ourselves bitten.

Perhaps I overreached with the word invalid, but I am of the opinion 
that if the type is XHTML that the content should be an xthml fragment.

atom:b and atom:strong elements are examples of things which one would 
not expect to find in xhtml.
Yes, but there are many other things people may get wrong when producing 
Atom. In particular, I would tend to trust those who do generate XHTML 
instead of HTML to get namespace declarations right as well.

Below are some comments that I just added to the Pace:
- Requiring the namespace declaration on a particular element means (a) 
profiling XMLNS, (b) defeating potential space optimizations by having 
the namespace declaration only once, and (c) breaks XML toolkits that do 
not provide full control over where namespace declarations appear.

- if this pace gets accepted, I would ask for the same DIV container 
element for HTML content for reasons of symmetry.

Best regards, Julian


--
green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760


Re: PaceXhtmlNamespaceDiv

2005-02-08 Thread Sam Ruby
Julian Reschke wrote:
Sam Ruby wrote:
Julian Reschke wrote:
Anne van Kesteren wrote:
Henri Sivonen wrote:
-1 on PaceXhtmlNamespaceDiv
-1 from me as well. It is hack which might be useful for publishing 
systems (and perhaps aggregators) who do not use the right tools to 
generate a valid Atom file anyway.
Same here: -1
Can I get one of you three to mock up what Tim's feed should look like?
http://www.imc.org/atom-syntax/mail-archive/msg12902.html
- Sam Ruby
I'm not sure I understand this request. We're not asking Tim or anybody 
else not to use div elements, we're asking not to be forced by the 
spec to select a specific way to emit XHTML when many others do as well.

So, this is a -1 on forcing feed creators to use a very specific 
serialization format.
This Pace does *not* force feed creators to use a very specific feed format.
Anne had this right... if this Pace is adopted, then the div is part of 
the format.  Otherwise, it is part of the content.

In other words, if Tim's content has a div element that he wishes to 
syndicate, he would simply nest that div.  This would be rare.

As it stands, the content that Tim is syndicating does not match the 
content on his site.

- Sam Ruby


RE: PaceHeadless

2005-02-08 Thread Bob Wyman

James M Snell wrote:
 My preference would be a link based alternative.
feed
   ...
   entry
 ...
 link rel=feed href=... /
   /entry
/feed
I'm tired of arguing this one, so, I'm just going to say this one
more time and leave it at that.
Linking to the feed is not an acceptable solution. It must be
possible to embed feed metadata in an entry in a feed and in an Entry
document. 
Users and their news aggregators expect to have access to source
feed title, author, etc. when entries or lists of entries are displayed. If
the feed metadata is not in the entries, then it will have to be fetched
before entries can be displayed to the user. Thus, we should expect that
whenever a feed is received that contains links to feeds, the aggregators
will immediately generate a storm of HTTP request to pull down the full
feeds which are linked to simply in order to extract the feed titles and
other metadata. The result will be bursts of network traffic. Most of the
bandwidth consumed will be an absolute waste. (i.e. Many feeds in the wild
today are as large as 100K bytes. You're suggesting a design that requires
all 100K bytes to be pulled down in order to extract a few bytes of title
data. This is silly.)
If Atom drops HeadInEntry (or the alternative equivalent mechanisms
such as feeder) and replaces it with a link to feed, we at PubSub will
simply not be able to use Atom as defined. Other providers of aggregators,
search engine results, synthetic feeds, etc. will come to the same
conclusion in time.
Have a good day. I'm sure you'll all be pleased to know that I won't
be bothering you about this in the next few days. Do what you will...

bob wyman
 



Re: PaceXhtmlNamespaceDiv

2005-02-08 Thread Julian Reschke
Sam Ruby wrote:
Nothing changes for Tim, he can continue to produce the output he's 
producing currently.

What Tim is syndicating does not match the content on his site.  Without 
this Pace, the div element would need to be considered part of the content.
What difference does this make in practice? HTML defines DIV as...
These elements define content to be inline (SPAN) or block-level (DIV) 
but impose no other presentational idioms on the content.

(http://www.w3.org/TR/html401/struct/global.html#edef-DIV)
  3) More feeds will be harder to read (that's why I asked you to
 experiment with alternate serializations.

Whether something is easier to read seems to be a matter of taste: I 
certainly prefer a globally scoped XHTML namespace declaration, and no 
additional DIV elements.

Fair.  However, a globally scoped XHTML namespace declaration will 
require every xhtml tag to be explicitly namespaced.
(unless we make it the default namespace, which usually won't make sense).
- Requiring the namespace declaration on a particular element means 
(a) profiling XMLNS, (b) defeating potential space optimizations by 
having the namespace declaration only once, and (c) breaks XML 
toolkits that do not provide full control over where namespace 
declarations appear.

Nothing in this pace requires such a declaration.
When a Text construct or atom:content's type is XHTML, require it to 
have a single xhtml:div as a child, and require that div to declare the 
XHTML namespace.

Am I looking at the wrong pace? 
(http://www.intertwingly.net/wiki/pie/PaceXhtmlNamespaceDiv)

- if this pace gets accepted, I would ask for the same DIV container 
element for HTML content for reasons of symmetry.

Are you suggesting that the following would need to be required for 
symmetry?

  lt;divgt; ... lt;/divgt;
Yes.
Suggesting this seems petty.
Best regards, Julian
--
green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760


Re: PaceXhtmlNamespaceDiv

2005-02-08 Thread Henri Sivonen
On Feb 8, 2005, at 15:44, Sam Ruby wrote:
What Tim is syndicating does not match the content on his site.  
Without this Pace, the div element would need to be considered part of 
the content.
What's the harm?
 However, a globally scoped XHTML namespace declaration will require 
every xhtml tag to be explicitly namespaced.
Or the Atom tags to be colonified.
Are you suggesting that the following would need to be required for 
symmetry?

  lt;divgt; ... lt;/divgt;
Suggesting this seems petty.
I agree. However, I have similar sentiments towards requiring the div 
with XHTML.

--
Henri Sivonen
[EMAIL PROTECTED]
http://iki.fi/hsivonen/


Re: PaceXhtmlNamespaceDiv

2005-02-08 Thread Henri Sivonen
On Feb 8, 2005, at 15:59, Julian Reschke wrote:
When a Text construct or atom:content's type is XHTML, require it 
to have a single xhtml:div as a child, and require that div to declare 
the XHTML namespace.

Am I looking at the wrong pace? 
(http://www.intertwingly.net/wiki/pie/PaceXhtmlNamespaceDiv)
The abstract no longer matches the proposal. This seems to cause 
confusion.

--
Henri Sivonen
[EMAIL PROTECTED]
http://iki.fi/hsivonen/


Re: PaceXhtmlNamespaceDiv

2005-02-08 Thread Sam Ruby
Julian Reschke wrote:
- Requiring the namespace declaration on a particular element means 
(a) profiling XMLNS, (b) defeating potential space optimizations by 
having the namespace declaration only once, and (c) breaks XML 
toolkits that do not provide full control over where namespace 
declarations appear.
Nothing in this pace requires such a declaration.
When a Text construct or atom:content's type is XHTML, require it to 
have a single xhtml:div as a child, and require that div to declare the 
XHTML namespace.

Am I looking at the wrong pace? 
(http://www.intertwingly.net/wiki/pie/PaceXhtmlNamespaceDiv)
I have just updated the Pace to remove from the abstract text which is 
no longer reflected in the proposal.

- Sam Ruby


Re: type=HTML

2005-02-08 Thread Sam Ruby
Julian Reschke wrote:
(http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.3.1.1) 

The spec currently says:
If the value of type is HTML, the content of the Text construct 
MUST NOT contain child elements, and SHOULD be suitable for handling by 
software that knows HTML. The HTML markup must be escaped; for example, 
br as lt;br. The HTML markup SHOULD be such that it could 
validly appear directly within an HTML DIV element. Receiving software 
which displays the content MAY use the markup to aid in displaying it.

Is there anything that we can say about what recipients should do if 
they are not prepared to tag-soup-parse HTML content (such as something 
based on XSLT1 in Mozilla or running in a size-constrained environment 
(does MIDP come with an HTML parser)? Skip the entry? Do not display the 
content? Display the content including the escaped markup as plain text?
I would suggest stripping the tags.  In Perl, something like this:
   s/.*?//g
Shouldn't we at least give content producers the hint that producing 
XHTML content is preferred over HTML? (sorry if I'm opening a can of 
worms here)
Depending on the target environment, stripping the elements in XHTML may 
also be appropriate.

- Sam Ruby


RE: PaceHeadless

2005-02-08 Thread Walter Underwood
--On Tuesday, February 08, 2005 08:39:42 AM -0500 Bob Wyman [EMAIL PROTECTED] wrote:
Linking to the feed is not an acceptable solution. It must be
possible to embed feed metadata in an entry in a feed and in an Entry
document.
+1
The feed document *must* be standalone. Everything required to
interpret the feed has to be in the feed.
wunder
--
Walter Underwood
Principal Architect
Verity Ultraseek


Re: PaceHeadless

2005-02-08 Thread James M Snell
Well, I ain't gonna argue the point, but I'm going to stick by the 
assertion that feeder/head is ugly.  Any use of this stuff I plan to 
make can live equally well with either approach.

- James M Snell
Walter Underwood wrote:
--On Tuesday, February 08, 2005 08:39:42 AM -0500 Bob Wyman 
[EMAIL PROTECTED] wrote:

Linking to the feed is not an acceptable solution. It must be
possible to embed feed metadata in an entry in a feed and in an Entry
document.

+1
The feed document *must* be standalone. Everything required to
interpret the feed has to be in the feed.
wunder
--
Walter Underwood
Principal Architect
Verity Ultraseek




Re: PaceArchiveDocument

2005-02-08 Thread Graham
On 8 Feb 2005, at 12:14 am, Eric Scheid wrote:
PaceArchiveDocument
-1
this looks like a backdoor to feeds in feeds.
-1, agreed.
Graham


Re: PaceDatesXSD

2005-02-08 Thread Graham
-1 on the regex. It's completely unreadable and hides whatever 
additional constraints it adds. Write those down in English please.

Graham


Re: type=HTML

2005-02-08 Thread Julian Reschke
Sam Ruby wrote:
Julian Reschke wrote:
(http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.3.1.1) 

The spec currently says:
If the value of type is HTML, the content of the Text construct 
MUST NOT contain child elements, and SHOULD be suitable for handling 
by software that knows HTML. The HTML markup must be escaped; for 
example, br as lt;br. The HTML markup SHOULD be such that it 
could validly appear directly within an HTML DIV element. Receiving 
software which displays the content MAY use the markup to aid in 
displaying it.

Is there anything that we can say about what recipients should do if 
they are not prepared to tag-soup-parse HTML content (such as 
something based on XSLT1 in Mozilla or running in a size-constrained 
environment (does MIDP come with an HTML parser)? Skip the entry? Do 
not display the content? Display the content including the escaped 
markup as plain text?

I would suggest stripping the tags.  In Perl, something like this:
   s/.*?//g
Thanks. Are we 100% confident that whatever results from that 
replacement can be safely embedded? For instance, what about script 
tags? Can they contain potentially dangerous code that would execute 
without being referenced from somewhere?

Shouldn't we at least give content producers the hint that producing 
XHTML content is preferred over HTML? (sorry if I'm opening a can of 
worms here)
Depending on the target environment, stripping the elements in XHTML may 
also be appropriate.
Sure, but for XHTML, the XML parser already contains the necessary 
machinery.

Anyway, the spec offers to alternatives (HTML and XHTML) that cover 
similar use cases. I think it would be good if it made a recommendation 
at least for those cases, where the producer already has XHTML content.

Best regards, Julian
--
green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760


Re: PaceDatesXSD

2005-02-08 Thread Norman Walsh
/ Graham [EMAIL PROTECTED] was heard to say:
| -1 on the regex. It's completely
| unreadable and hides whatever
| additional constraints it adds. Write
| those down in English please.

Well, how about English and the regex? I'm worrying about
interoperability here. There's considerable pressure to use RFC 3339,
but I can't think of any practical, interoperable way to use RELAX NG
or W3C XML Schema to constrain the value of Date Constructs to RFC
3339. (I could do it by defining my own data type in RELAX NG, but
that wouldn't be interoperable; I could do it by using just
xsd:dateTime, but that wouldn't be constraining enough.)

I suppose I could just use the combination of xsd:dateTime and the
regular expression in my schema to implement the prose if we took the
regex out of the spec.

*shrug* It's been a long, hard day and I don't have any fight left in
me. Given that I'm reasonably confident that xsd:dateTime+regex is
isomorphic to the set of RFC 3339 date-times that we want to allow,
I'll accept whatever the group decides.

Be seeing you,
  norm

-- 
Norman Walsh [EMAIL PROTECTED] | We learn from experience that not
http://nwalsh.com/| everything which is incredible is
  | untrue.--Cardinal De Retz


pgp0ZHDBcLdRp.pgp
Description: PGP signature


Re: type=HTML

2005-02-08 Thread Martin Duerst
At 23:36 05/02/08, Julian Reschke wrote:
Shouldn't we at least give content producers the hint that producing 
XHTML content is preferred over HTML? (sorry if I'm opening a can of worms here)

I'd be very much in favor of that. The first step is to order the sections
so that XHTML comes first. I have suggested this before. This is very close
to editorial, but can already give some hint.
The second is to add a sentence such as this: Content producers that can 
produce
both XHTML content and HTML content SHOULD produce XHTML content.
Regards,Martin. 



Re: PaceXhtmlNamespaceDiv

2005-02-08 Thread Martin Duerst
At 22:59 05/02/08, Julian Reschke wrote:
http://www.intertwingly.net/wiki/pie/PaceXhtmlNamespaceDiv
I have looked at this pace only just very recently, after
following the discussion. So I first want to make sure I
get the current status of this proposal right.
As I currently read it, it does:
1) Require an xhtml:div as the only direct child of content of type XHTML
2) Not limit the placement of namespace declarations in any way above
   and beyond those given in the Namespace spec.
3) Not require any specific namespace prefixes.
If 2) and 3) are correct, I can live with this proposal. Anything
changing 2) or 3), as may have been previously in this Pace, would
get something like a -2 from me. Specs, in particular such fundamental
ones as XML Namespaces, are there to be used as is, not to be tweaked.
As for 1), I could live with it, but the rationale given for it in the
current version says:
Given that even we often forget when writing examples to declare
 the XHTML namespace for XHTML text constructs and content elements,
 it seems likely that people producing actual feeds will forget
 to do so unless the requirement to do so is stated prominently
 and unambiguously.
This doesn't seem to match the proposal, where Namespace declarations
are only used in the examples, but not mentioned in the text.
So while (as said above) I can live with 1), insisting on 1) without
a better rationale doesn't seem to make sense to me.
If the concern expressed in the rationale is important (and I can
agree it is), then addressing this concern can be done in less
constricting ways, i.e. by replacing the requirement for a div
with something like:
Note: It is important to make sure that correct namespace declarations
for XHTML are present. One way to do this is by using an xhtml:div
element as the content of the atom:content element and specifying
the XHTML namespace on that div element. Here are some examples:
... [use proposed examples]
There are other ways to declare the namespace URI for XHTML content;
this specification does not limit the placement of such declarations
in any way.
Regards, Martin.


Re: PaceXhtmlNamespaceDiv

2005-02-08 Thread Eric Scheid

On 9/2/05 3:39 PM, Martin Duerst [EMAIL PROTECTED] wrote:

 Note: It is important to make sure that correct namespace declarations
 for XHTML are present. One way to do this is by using an xhtml:div
 element as the content of the atom:content element and specifying
 the XHTML namespace on that div element. Here are some examples:
 ... [use proposed examples]
 There are other ways to declare the namespace URI for XHTML content;
 this specification does not limit the placement of such declarations
 in any way.

+1