Re: The atom:uri element

[A. Pagaltzis]

* Asbjørn Ulsberg <[EMAIL PROTECTED]> [2005-05-24 14:50]:
> I've mentioned this several times before and haven't had time
> to follow  the evolvement of the draft up until now, but as far
> as I can tell,  atom:uri is still in place in the
> specification... Do we really need a  pace to have that element
> renamed before the spec goes final?

-1 to renaming the element.
See http://www.imc.org/atom-syntax/mail-archive/msg13864.html

> Or is it so that the atom:uri element have many proponents on
> the list so  it can't be renamed or changed to atom:link,
> atom:email or something  making more sense? Even atom:iri is
> better at this point, imho.

Is there anything for which atom:uri is insufficient, which can
plausibly not be done in an extension, and for which there is a
pressing need? And if so, how do atom:link semantics apply to
person constructs?

-1 to atom:link. No need for change for the sake of change.

Regards,
-- 
Aristotle

Re: The atom:uri element

[Eric Scheid]

On 25/5/05 2:34 PM, "James Cerra" <[EMAIL PROTECTED]> wrote:

> I agree with this.  I thought it was unusual to name a tag after a specific
> technology rather than its intent (atom:email is an exception).  In this
> instance, I think atom:name, atom:resource, or atom:link works better.

+1 atom:link

e.

Re: The atom:uri element

[James Cerra]

> > Or is it so that the atom:uri element have many proponents on the list  
> > so it can't be renamed or changed to atom:link, atom:email or something  

I agree with this.  I thought it was unusual to name a tag after a specific
technology rather than its intent (atom:email is an exception).  In this
instance, I think atom:name, atom:resource, or atom:link works better.

> Just so the replies to this e-mail (if any) doesn't get concentrated  
> around my little mishap with the elements here: I didn't mean writing  
> 'atom:email' there since we already have that element. The point I'm  
> trying to make is not the name of the element, but rather its type. I'd  
> like it to be constructed somewhat similar to atom:link, e.g. be an Atom  
> Link Construct.

Good point.  I like the idea of adopting atom:link if several identifiers per
person is allowed.  Or what about an "href" or "ref" attribute on the author
element, if only one indentifier is intended per author?  Or an "about" or
"res" attribute if the uri isn't intended to be dereferenceable?  Just
brainstorming some alternatives.

-- Jimmy Cerra



__ 
Do you Yahoo!? 
Make Yahoo! your home page 
http://www.yahoo.com/r/hs

Re: atom:type, xsl:output

[James Cerra]

Graham,

> > Secondly, XML may be entity (or CDATA) encoded like
> > @type="html" or plain xml like @type="xhtml".  This is
> If I follow you right, you misunderstand. Atom documents are  
> unambiguous. XML has to be inserted literally, with no entity  
> escaping (except for entities that are part of text nodes) allowed.

I'm not so sure.  The spec seems to hint at the answer, but provides no
cannonical interpretation like it does with @type="html".

After being processed by a XML processor, any entites should be dereferenced to
their text values and placed into the document tree.  So this:

> > 
> > 
> > 

would become the text string:

> > 
> > http://smallbusiness.yahoo.com/resources/

Re: atom:type, xsl:output

[James Cerra]

Aristotle,

> Embedding XML 1.1 documents inside an XML 1.0 document is not
> possible, because...

I understand.  Thanks.

> An Atom processor does not know whether the embedded XML document
> is a valid document of the given type. Only an attached processor
> for the given document type will be able to decide. As such, the
> validity of the Atom feed document is not affected by the media
> type. It will, of course, cause interop problems if you lie about
> the media type, hence SHOULD.

That's convincing.

> > Secondly, XML may be entity (or CDATA) encoded like
> > @type="html" or plain xml like @type="xhtml".  This is becuase
> > of the "content of atom:content MAY include child elements"
> > phrase.  There is no guarantee if an entity escaped passage is
> > xml or a text node example of an xml document (i.e. an example
> > of an xml document), for example.
> 
> No. Wrong.
> 
> There is nothing saying that the content of atom:content MAY be a
> text node. It MAY only be a child element.

If it may be an element, then it may be something else too.  By the definition
in RFC 2119, this behavior (having one or more child elements according to
20050418 revision) is "truly optional."  There's three other things it could be
(ignoring comments and PIs): a text node, mixed content, no nothing at all.  So
it is still a valid Atom fragment.

> If there is no child element, @src must be set, ie the XML
> document constituting the content is external to the feed.
> 
> I will say, though, the the spec could stand to be more explicit
> in this instance.

I agree with both your commentary on the spec and that your interpretation is
mostly what Atom should support.  Here's how I would write it:

"4. If the value of "type" ends with "+xml" or "/xml" (case-insensitive), the
content of atom:content MUST either consist of no children or one or more XML
1.0 elements, comments, processing instructions, an XML 1.0 text node, or mixed
content [1].  Any comments, processing instructions, or entities found as
children of atom:content MUST be interpreted as being associated with the Atom
document itself.  If the intended Atom content contains essential comments,
processing instructions, entities, DOCTYPE declaration(s), or other properties
that make it unable to be valid atom:content content, then it MAY be specified
in an external file identified by a URI in the the "src" attribute, which MAY
be interpreted by an Atom processor as being associated as the Atom content of
the entry.  The Atom content of the entry SHOULD be suitable for handling as
the indicated media type."

I defined a phrase, "Atom content," to represent the content of an entry, that
is refernced by atom:content either through its src attribute or literally as
its children elements and text nodes.  Any comments or processing instructions
should be explicitly associated with the Atom document's xml, rather than the
"Atom content", so style information can be applied (for viewing the raw Atom
XML) and the processing order of processing instructions and comments is well
defined (to solve the problem of which ones to read and which ones to pass?)
for examples.

That paragraph is also very long-winded, but I think it is more precise than
the existing paragraph.  I don't know if it is deterministic, whatever that is,
and I still think some of the attributes of xsl:output should be included as
optional metadata about the atom:content child (doctype, xml declaration, etc.)
if it is a complete document.

--
Jimmy Cerra

[1] 



__ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new Resources site
http://smallbusiness.yahoo.com/resources/

Re: Review of Atom 0.8 Spec against W3C QA Specification Guidelines

[Karl Dubost]

Le 05-05-24 à 21:04, A. Pagaltzis a écrit :

So it seems to me that your complaint is outside the scope of the
specification, and, indeed, this WG.


I had a lengthy discussion with Paul Hoffman out of the list to avoid  
unnecessary arguments on this list which has suffered it in the past.  
Just to remind the tone of my messages, it was not "complaints", it  
was "suggestions". I'm not asking people to do things with it. And I  
just replied to comments when people were asking about conformance. :)


I still don't understand the first message of Paul, but that's  
another story which has no place on this list.




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

Re: inheritance issues (was: Author and contributor)

[A. Pagaltzis]

* Thomas Broyer <[EMAIL PROTECTED]> [2005-05-24 15:15]:
> A. Pagaltzis wrote:
> > * Thomas Broyer [2005-05-24 09:05]:
> >> c)
> >> feed:
> >>   author: A
> >>   contributor: B
> >>   entry:
> >> contributor: C
> [...]
> >> c) The entry inherits the author but overrides the
> >>contributor. I'm also open to considering it invalid.
> [...]
> > Effectively, I am proposing:
> >
> > A non-empty set of atom:entry/atom:author overrides any set
> > of atom:feed/atom:author and atom:feed/atom:contributor.
> >
> > atom:contributor may only appear if ../atom:author is also
> > given.
> 
> If you just consider c) to be invalid, you can go with:
> 
> A non-empty set of both atom:entry/atom:author and
> atom:entry/atom:contributor overrides any set of both
> atom:feed/atom:author and atom:feed/atom:contributor.

That seems to allow entries with contributors, but no author. You
need to be more precise.

> or
> 
> If an atom:entry has neither an atom:author nor an
> atom:contributor child element, the author(s) of and
> contributor(s) to the entry are those specified at the feed
> level, that is, those appearing as children of an
> atom:source or, if the atom:entry contains no atom:source
> child element, those appearing as children of the atom:feed
> element.
> 
> Note that if an entry has no atom:author or
> atom:contributor child but contains an atom:source child.
> If the atom:source element contains no atom:author or
> atom:contributor child, the entry has no author or
> contributor. In such a case, the atom:author and
> atom:contributor children of the atom:feed element don't
> cascade into the atom:entry.
> 
> (and again, excuse me for my English, it's not my mother tong)

I think this clearly demonstrates why I opted for disallowing
atom:contributor in absence of ../atom:author: it is difficult to
explain. You need a lot of prose to express it. You also need
more code and more grammar rules. To me, that raises flags that
it’s too complex.

Only the atom:content section of the specification contains
restrictions on any single “aspect” which are not expressible in
one or two sentences and cannot be understood in near isolation.

> Please note that I am not proposing changing atom:author and
> atom:contributor to atom:person with a role property. This is
> just to make clearer my proposal of "considering atom:author's
> and atom:contributor's" as a whole, not atom:author's in one
> hand and atom:contributor's in the other hand".

It would be much easier to explain your proposal if that were the
case; and in that case I would be in favour. But we have two
separate elements, and that’s not going to change…

I’m not opting for the best possible solution; I’m trying to
suggest something that, given the current state of the
specification, will require the least changes for the most
effect.

> -0 to forbidding contributors without author at the feed level.

Actually, me too. Banning feeds with only contributors does not
make the actual documents any more precise, so conceptually I
don’t like the restriction. But it makes everything that deals
with the documents simpler, so I accept it.

Regards,
-- 
Aristotle

Re: Review of Atom 0.8 Spec against W3C QA Specification Guidelines

[A. Pagaltzis]

* Karl Dubost <[EMAIL PROTECTED]> [2005-05-24 20:05]:
> > > It means that all XSLTs, Web hosting services, etc can NOT
> > > claim conformance to Atom. :)
> >
> > Yes they can.
> 
> no for the reason I gave and no because there's no way to claim
> conformance to the spec. They are plenty marketing department
> which  will claim conformance to something even if they have a
> bad support  of it :) Which has after implications in the world
> of markets,  business offering and certifications which leads
> to quagmires.

If something produces documents that conform to the rules set out
for Atom Documents in the Atom Format specification, then it
produces Atom Documents. Are you suggesting that it makes sense
to state conformance in any other terms? If so, why?

I *could* see an argument for defining when an Atom Processor is
conformant; after all, interpreting a document is more ambiguous
job than generating one, and many desktop aggregators have poor
support for the full link model, f.ex.

Your complaints seem to hinge on a belief that the scope of the
specification should extend further than to specify exactly what
a document means. My understanding is that the WG has decided
that the format specification is to say exactly what the bits on
the wire mean, but not what how anyone should generate them or
what anyone should do with them once they have received them.

So it seems to me that your complaint is outside the scope of the
specification, and, indeed, this WG.

Regards,
-- 
Aristotle

Re: extension elements inside link elements?

[A. Pagaltzis]

* Thomas Broyer <[EMAIL PROTECTED]> [2005-05-24 20:10]:
> What about:
> 
>The "atom:link" element defines a reference from an entry or
>feed to a Web resource. Atom doesn't define any child to the
>"atom:link", though it might contain extension markup.

I may be trying to pick a colour for the bikeshed, but is an
explicit mention of the possibility of extension elements really
necessary? Unnecessary redundancy is an invitation for
inconsistencies.

Regards,
-- 
Aristotle

Re: extension elements inside link elements?

[Robert Sayre]

On 5/24/05, Graham <[EMAIL PROTECTED]> wrote:
> On 24 May 2005, at 5:44 pm, Robert Sayre wrote:
> 
> > FYI:
> > http://www.imc.org/atom-syntax/mail-archive/msg11433.html
> >
> > "But if I encounter a  element that's weirdly non-empty and
> > contains markup from some other namespace, that's the kind of
> > situation you're talking about. I think it would be OK to leave
> > behavior undefined as you say."
> 
> I'm not sure I object to it in principle, though I think it's a weird
> place for someone to put extentsions, but I object to it being
> characterised as an editorial change.

Well, that's how the reviewer felt, and I though it was a super minor
change. Also, I observe that more than 3 or 4 WG members have
expressed a desire to extend it that way. I can't think of a problem
with that, though I would surely ignore them when processing a link
element.

> I also think removing that piece of text makes it unclear that the
> element is normally empty.

I don't think so. There's an example just below, in 4.2.9.2. We could
show some more examples. The other element with no defined content is
atom:category. Its RNC illustration also shows it as empty, but the
text doesn't call it an "empty element."

Robert Sayre

Re: Comments about Extensions (1)

[Robert Sayre]

On 5/24/05, Thomas Broyer <[EMAIL PROTECTED]> wrote:
> 
> David Powell wrote:
> 
> >Section 6.4:
> >
> >The RNGs in this section require Extension Elements to be in a
> >namespace that isn't the Atom namespace. This requirement is missing
> >from the text.
> >
> >
> 
> It's actually worse than just that.

Actually, I don't see a problem here. You just don't understand that
some extension content has its role defined by the spec ahead of time,
and some doesn't ("undefined"). I don't see any reason to revisit
this.

bye,

Robert Sayre

Re: Comments about Extensions (1)

[Thomas Broyer]

David Powell wrote:


Section 6.4:

The RNGs in this section require Extension Elements to be in a
namespace that isn't the Atom namespace. This requirement is missing
from the text.
 



It's actually worse than just that.

Section 6.1 defines "foreign markup" as being "markup from other 
vocabularies". WRT section 6.2 describing "extensions to the Atom 
vocabulary", I understand this definition of "foreign markup" as "markup 
in a namespace different from the Atom one.


Section 6.4 *implies* Extension Elements are foreign markup as the first 
sentence of that section is "Atom allows foreign markup anywhere in an 
Atom document" though it's not explicit at all.


Having re-read the draft without looking at the RNC excerpts, the whole 
section 6 with its subsections are totally unclear about what is 
"foreign markup" (or what is behind "Atom vocabulary"), what are 
"extensions", what are Simple/Structured Extension Elements and how they 
relate to foreign markup.


Even more, I'm wondering why would there be a need to define 
Simple/Structured Extension Elements in terms of "constraints". I 
suppose that it's a way to distinguish extensions in the form 
text-only from extensions using attributes 
and/or child elements; and such a distinction is only necessary because 
we want to provide a hint about how to interpret extensions in the 
former form (no attribute, text-only content).
Wouldn't it be clearer (less obscure) to anyone dropping section 6.4 and 
just saying something like the following:


   Elements from foreign markup with no attribute and text-only content
   MAY be interpreted by an Atom Processor as a property (or name/value
   pair) of the parent element that encloses it. This specification
   does not provide an interpretation for other elements.

Still about extensions, have I missed something or nowhere the spec 
allows for "extension attributes" (I mean namespaced attributes 
appearing on Atom elements)? I suggest such attributes to be interpreted 
as a property (or name/value pair) of the element on which it appears.


Finally, in section 6.2, in the last sentence, "for the purpose of this 
discussion" applies only to the section 6.3 about how to process them: 
they obviously aren't "extensions", are they? I suggest moving this 
sentence into section 6.3.


There might be other things I missed this evening...

--
Thomas Broyer

Re: Review of Atom 0.8 Spec against W3C QA Specification Guidelines

[Paul Hoffman]

At 2:51 PM -0400 5/24/05, Karl Dubost wrote:

Are you insecure?


Well, I do sometimes worry my protocols aren't as long as those from 
other Working Groups, but I try not to think about it.



Where did you read, imagine such a thing?
The case has been settled for a long time by choice of the Atom 
Community. No trouble.


OK, good. So why are we discussing where the Atom format document 
doesn't match up to W3C test specification guidelines?



Did you miss an email?


No.

[[[I have done the review of Atom 0.8 to ___test___ W3C QA 
Specification Guidelines with an external technical document and I 
thought it could be also useful to the Atom community.

]]] - http://www.imc.org/atom-syntax/mail-archive/msg15675.html


Right. You didn't say why you thought it would be useful, and then...


and the rest, I'm replying to the questions. :)


That's the part that is confusing. Your responses sound a great deal 
like we should be making changes to our documents based on W3C test 
guidelines. For what purpose?


--Paul Hoffman, Director
--Internet Mail Consortium

Re: extension elements inside link elements?

[Tim Bray]

On May 24, 2005, at 10:43 AM, Graham wrote:

I also think removing that piece of text makes it unclear that the  
element is normally empty.


+1 -Tim

Re: extension elements inside link elements?

[Tim Bray]

On May 24, 2005, at 9:26 AM, Graham wrote:


4.2.9 (editorial):  The atom:link element is explicitly described as
empty, which violates the rules in 6 for foreign element extension.
Remove "is an empty element that".



That's not an editorial change, that's newly allowing extension  
elements in a place most people (such as Paul and myself) assumed  
they weren't.


On the one hand I agree with Graham; this does feel like a  
substantial change.  On the other, it's hard to see that having stuff  
inside  would do any damage; I best most software would never  
notice it.  Having said that, I don't agree that it's editorial  
change and I'd like to see a couple more voices in favor and give  
people a chance to shout "No!" before going ahead and doing it. -Tim

Re: atom:type, xsl:output

[Tim Bray]

On May 24, 2005, at 1:25 AM, Graham wrote:


First off: it is an error to lie about your
media-type, so I would change "SHOULD be suitable for
handling as the indicated media type" to "MUST be
suitable for handling as the indicated media type."



+1


I'm tempted to agree but can't, because the condition of "being  
suitable for handling as" is not deterministic and testable enough to  
merit a MUST. -Tim

Re: extension elements inside link elements?

[David Powell]

Tuesday, May 24, 2005, 7:50:13 PM, Thomas Broyer wrote:

> David Powell wrote:

>>Whether the draft allowed it or not, atom:link isn't an extension
>>point.
>>  
>>
> Could you explain why?

The following are extension points:

* Adding additional metadata to atom:feed by using Section 6.4
Extension Elements.

* Adding additional metadata to atom:entry by using Section 6.4
Extension Elements.

* Adding additional metadata to Person Constructs by using Section 6.4
Extension Elements.

* Adding new atom:link types by using new @rel attributes.

* Embedding arbitrary data by using atom:content.


Atom processors won't fail if you put elements in other places, but I
didn't think that they were extension points.

-- 
Dave

Re: extension elements inside link elements?

[David Powell]

Tuesday, May 24, 2005, 8:24:16 PM, Graham wrote:

> On 24 May 2005, at 7:08 pm, David Powell wrote:

>> Whether the draft allowed it or not, atom:link isn't an extension
>> point. That would be Section 6.3 style "unknown foreign markup".

> Unless there's a memo I missed, extensions are a subset of "unknown
> foreign markup".

That is what I said isn't it?  Some "unknown foreign markup" is an
extension.

-- 
Dave

Re: extension elements inside link elements?

[Graham]

On 24 May 2005, at 7:08 pm, David Powell wrote:


Whether the draft allowed it or not, atom:link isn't an extension
point. That would be Section 6.3 style "unknown foreign markup".


Unless there's a memo I missed, extensions are a subset of "unknown  
foreign markup".


Graham

Comments about Extensions (1)

[David Powell]

Section 6.4:

The RNGs in this section require Extension Elements to be in a
namespace that isn't the Atom namespace. This requirement is missing
from the text.

Proposal


Add to section 6.4.1:

> A Simple Extension Element MUST be namespace-qualified. The element
> MUST be defined outside of the Atom namespace.

Add to section 6.4.2:

> The root element of a Structured Extension element MUST be
> namespace-qualified. The element MUST be defined outside of the Atom
> namespace.


-- 
Dave

Re: extension elements inside link elements?

[Thomas Broyer]

David Powell wrote:


Whether the draft allowed it or not, atom:link isn't an extension
point.
 


Could you explain why?

--
Thomas Broyer

Re: Review of Atom 0.8 Spec against W3C QA Specification Guidelines

[Karl Dubost]

Le 05-05-24 à 14:31, Paul Hoffman a écrit :
I am completely unclear why this discussion is going on. Is there a  
desire on the part of the W3C to take the Atom work into the W3C?


Are you insecure?
Where did you read, imagine such a thing?
The case has been settled for a long time by choice of the Atom  
Community. No trouble.


If so, talking to the W3C/IETF liaison pair would be more  
appropriate than this mailing list. If not, then suggesting that  
our document should be more W3C-like seems fairly out-of-scope for  
an IETF WG.


[I just removed initial thought here.]


Could you clarify?


Did you miss an email?

[[[I have done the review of Atom 0.8 to ___test___ W3C QA  
Specification Guidelines with an external technical document and I  
thought it could be also useful to the Atom community.

]]] - http://www.imc.org/atom-syntax/mail-archive/msg15675.html

and the rest, I'm replying to the questions. :)

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

Re: Review of Atom 0.8 Spec against W3C QA Specification Guidelines

[Paul Hoffman]

I am completely unclear why this discussion is going on. Is there a 
desire on the part of the W3C to take the Atom work into the W3C? If 
so, talking to the W3C/IETF liaison pair would be more appropriate 
than this mailing list. If not, then suggesting that our document 
should be more W3C-like seems fairly out-of-scope for an IETF WG.


Could you clarify?

--Paul Hoffman, Director
--Internet Mail Consortium

Re: extension elements inside link elements?

[David Powell]

Tuesday, May 24, 2005, 9:22:29 AM, Eric Scheid wrote:

>> 4.2.9 The "atom:link" Element
>> 
>> The "atom:link" element is an empty element that defines a reference from an
>> entry or feed to a Web resource.

> Subject: Re: extension elements inside link elements?

> did we want to prevent expressions like this:

> 
> 
> 

> e.

Whether the draft allowed it or not, atom:link isn't an extension
point. That would be Section 6.3 style "unknown foreign markup".


-- 
Dave

Re: extension elements inside link elements?

[Thomas Broyer]

Graham wrote:



On 24 May 2005, at 5:44 pm, Robert Sayre wrote:


FYI:
http://www.imc.org/atom-syntax/mail-archive/msg11433.html

"But if I encounter a  element that's weirdly non-empty and
contains markup from some other namespace, that's the kind of
situation you're talking about. I think it would be OK to leave
behavior undefined as you say."



I'm not sure I object to it in principle, though I think it's a weird  
place for someone to put extentsions,


What about the following extension?
http://example.com/some/negociated/content";>
  image/svg+xml
  image/png
  image/jpeg


I also think removing that piece of text makes it unclear that the  
element is normally empty.


What about:

   The "atom:link" element defines a reference from an entry or feed to
   a Web resource. Atom doesn't define any child to the "atom:link",
   though it might contain extension markup.

--
Thomas Broyer

Re: inheritance issues

[Antone Roundy]

On Tuesday, May 24, 2005, at 10:21  AM, Walter Underwood wrote:

Inheriting values saves typing. It does not save bandwidth, because
HTTP compression will do nearly as well.


6% of the feeds I subscribe to use compression.  I don't think we can 
depend on that yet.

Re: Review of Atom 0.8 Spec against W3C QA Specification Guidelines

[Karl Dubost]

Le 05-05-24 à 12:19, James Aylett a écrit :

The implication (and I think it's pretty clear, but perhaps I'm used


Implication :) You just name it and that's the source of lng  
(endless) discussions when specs are released.




What is a conformant Atom Authoring Tool?


The term "Atom Authoring Tool" isn't in the draft, and it doesn't  
need to be.


why?


 It means that all XSLTs, Web hosting
services, etc can NOT claim conformance to Atom. :)


Yes they can.


no for the reason I gave and no because there's no way to claim  
conformance to the spec. They are plenty marketing department which  
will claim conformance to something even if they have a bad support  
of it :) Which has after implications in the world of markets,  
business offering and certifications which leads to quagmires.




They just can't claim to be Atom Processors unless they
abide by the rules for Atom Processors (and abide by any definition of
Atom Processors).


There's none.


Something that produces an XML document that abides
by every normative part of the Atom spec (including honouring every
MUST clause) that applies to Atom Feed Documents can be considered
something that 'conforms' to the Atom spec for producing such a
document.


Conformity of a document is not conformity of a product. Two  
different classes of products.



Or, more clearly, it produces Atom Feed Documents. If it
produced something it claimed were Atom Feed Documents that weren't
conformant, they wouldn't be Atom Feed Documents.


Documents and Softwares are not the same thing.


How can it be misinterpreted more than by giving the idea there might
be 'nonconformant' documents in some way? Can't we just assume that
the purpose of the spec is to define a document format (well, two
formats) that you (as a producer, consumer or whatever) can conform to
if you want? (And if you don't want, go do something else :-)



I see also
"Atom Processors handle URIs."

"handle" is not an RFC 2119. It means that it's not even optional,
and not mandatory. Is it ok? Maybe "Atom Processors MUST handle  
URIs."?


Why is it not optional or mandatory? It's a declaration of something
that an Atom Processor does - I take it as being a "by definition",
with reference to earlier statements of RFC 2119 requirement in the
document.


You said it: "You take it" and I take it differently :) Our  
discussion here exactly shows that there's room for misinterpretation  
and nothing is obvious in a technical specification.
But don't worry I will not insist too much. If the Atom community  
considers it's enough for a good specification. Why not? The purpose  
of the exercise was to give help on things that might create troubles.



Actually, since this is in the context of a security consideration,
it's not a restriction on the processors AT ALL.


Where what you just said is explained. You said before that  
everything which is in the spec is normative and now you are saying  
that this part is not normative? I'm lost or does it show that it's  
important to know which part of the specifications are informative  
and which ones are normative?
http://atompub.org/2005/04/18/draft-ietf-atompub- 
format-08.html#rfc.section.8



It's saying "since
Atom Processors are going to have to work with URIs/IRIs - they'll
have to handle them - implementors should consult RFC3986 and RFC3987
for security considerations in doing this".


where ?


In the prose before it is said:
"If the "src" attribute is present, Atom Processors MAY use the IRI
to retrieve the content. "

What is the behavior of the Atom processor when the MAY is not
implemented because it's optional and because it's not mandatory for
"Atom Processors" to handle URIs or IRIs.



If we assume, as is I think reasonable, that handling URIs/IRIs is
something that Atom Processors do by definition, then the last half of
that question isn't relevant.


"Assume" MUST not be part of a technical specification. That's the  
whole problem here ;)




The behaviour of the Atom processor when the MAY is not implemented is
that the Atom processor doesn't retrieve the content. So it doesn't
have the content, which it may not care about.


No consensus to make the schema normative. Everyone had a different
reason for opposing it, as I recall. :)



:)))
no more feed validator then. :)


A feed validator doesn't have to use a schema, but it could use it for
a non-normative check ("you may have problems" - or even kicking in
more lengthy checking code only when the schema is violated). This is
up to the validator authors.


Validation is something very precise. It can be validated against a  
DTD, or against a Schema or another grammar language, etc. At least  
the "Feed validator" could become a "Feed checker" which develops a  
heuristic to check if the requirements of the specification are  
verified. :))) "up to the validator authors" :)



Anyway. :))) It was just a message to help. :)

--
Karl Dubost - http://www.w3.org/People/karl/
W3C 

Re: extension elements inside link elements?

[Graham]

On 24 May 2005, at 5:44 pm, Robert Sayre wrote:


FYI:
http://www.imc.org/atom-syntax/mail-archive/msg11433.html

"But if I encounter a  element that's weirdly non-empty and
contains markup from some other namespace, that's the kind of
situation you're talking about. I think it would be OK to leave
behavior undefined as you say."


I'm not sure I object to it in principle, though I think it's a weird  
place for someone to put extentsions, but I object to it being  
characterised as an editorial change.


I also think removing that piece of text makes it unclear that the  
element is normally empty.


Graham

Re: inheritance issues

[Walter Underwood]

--On May 24, 2005 7:39:40 AM -0600 Antone Roundy <[EMAIL PROTECTED]> wrote:
> On Tuesday, May 24, 2005, at 01:52  AM, Henry Story wrote:
>> Simplify, simplify. I am for removing all inheritance mechanisms...

+1. Inheritance has very minor advantages and very serious disadvantages.

Inheriting values saves typing. It does not save bandwidth, because
HTTP compression will do nearly as well.

It is confusing and tricky to specify and implement. It makes the entry
different when it is standalone or in a feed. It multiplies the number
of test cases needed for validation.

Any one of those problems is serious.

wunder
--
Walter Underwood
Principal Architect, Verity

Re: extension elements inside link elements?

[Robert Sayre]

On 5/24/05, Graham <[EMAIL PROTECTED]> wrote:
> On 24 May 2005, at 4:07 pm, Robert Sayre wrote:
> 
> > 4.2.9 (editorial):  The atom:link element is explicitly described as
> > empty, which violates the rules in 6 for foreign element extension.
> > Remove "is an empty element that".
> 
> That's not an editorial change

FYI:
http://www.imc.org/atom-syntax/mail-archive/msg11433.html

"But if I encounter a  element that's weirdly non-empty and
contains markup from some other namespace, that's the kind of
situation you're talking about. I think it would be OK to leave
behavior undefined as you say."

Robert Sayre

Re: extension elements inside link elements?

[Robert Sayre]

On 5/24/05, Graham <[EMAIL PROTECTED]> wrote:
> On 24 May 2005, at 4:07 pm, Robert Sayre wrote:
> 
> > 4.2.9 (editorial):  The atom:link element is explicitly described as
> > empty, which violates the rules in 6 for foreign element extension.
> > Remove "is an empty element that".
> 
> That's not an editorial change, that's newly allowing extension

Fully disagree. The extensibility sectin is quite clear.

> elements in a place most people (such as Paul and myself) assumed
> they weren't.

I don't know anything about "most people" and neither do you. Paul
stated the meaning of the text of in question, no his own thoughts on
the matter.

Why don't you work on the problems in the draft instead of dwelling on
this tiny nitpick?

Robert Sayre

Re: extension elements inside link elements?

[Graham]

On 24 May 2005, at 4:07 pm, Robert Sayre wrote:


4.2.9 (editorial):  The atom:link element is explicitly described as
empty, which violates the rules in 6 for foreign element extension.
Remove "is an empty element that".


That's not an editorial change, that's newly allowing extension  
elements in a place most people (such as Paul and myself) assumed  
they weren't.


Graham

Re: Review of Atom 0.8 Spec against W3C QA Specification Guidelines

[James Aylett]

On Tue, May 24, 2005 at 11:08:26AM -0400, Karl Dubost wrote:

> Let's go a bit further though. Let's say I'm a developer who's  
> creating an authoring tool for Atom, so more a producer than a  
> consumer application.
> 
> "Atom Feed Documents"
> "Atom Entry Documents"
> 
> I read "An Atom Entry Document represents exactly one Atom entry,  
> outside of the context of an Atom feed. Its root is the atom:entry  
> element."
> 
> Nowhere it is said that
> "the root element of a conformant Atom Entry Document MUST be  
> "atom:entry"."

The implication (and I think it's pretty clear, but perhaps I'm used
to IETF documents) is that if we don't talk about MUST and SHOULD and
MAY, then a statement is an absolute requirement. We're saying that an
Atom Entry Document has a root which is an atom:entry element. So if
you have something that has a root that's something else, there's no
way it can be an Atom Entry Document.

I actually think that having a "conformant" layer is often bad -
because it suggests that "nonconformant" Atom Entry Documents might
exist and might mean something. By avoiding doing this, we define what
an Atom Entry Document is, and if you create something that doesn't
follow with that definition, you don't have an Atom Entry Document.

> What is a conformant Atom Authoring Tool?

An "Atom Authoring Tool" would be an authoring tool (however you want
to define it) that in some way uses Atom. Again, I don't see the need
for the word 'conformant'. The term "Atom Authoring Tool" isn't in the
draft, and it doesn't need to be.

> The specification says at the start: "This specification describes  
> conformance in terms of two artifacts; Atom Feed Documents and Atom  
> Entry documents. Additionally, it places some requirements on Atom  
> Processors."
> 
> If I read through the text "Atom Processors" are seen as consumers  
> application, not producers. It means that all XSLTs, Web hosting  
> services, etc can NOT claim conformance to Atom. :)

Yes they can. They just can't claim to be Atom Processors unless they
abide by the rules for Atom Processors (and abide by any definition of
Atom Processors). Something that produces an XML document that abides
by every normative part of the Atom spec (including honouring every
MUST clause) that applies to Atom Feed Documents can be considered
something that 'conforms' to the Atom spec for producing such a
document. Or, more clearly, it produces Atom Feed Documents. If it
produced something it claimed were Atom Feed Documents that weren't
conformant, they wouldn't be Atom Feed Documents.

> I know it sounds strange. You can decide in the specification to
> forbid such a claim too, but at least it's better to be explicit
> than "obvious hidden meaning" which might be misinterpreted.

How can it be misinterpreted more than by giving the idea there might
be 'nonconformant' documents in some way? Can't we just assume that
the purpose of the spec is to define a document format (well, two
formats) that you (as a producer, consumer or whatever) can conform to
if you want? (And if you don't want, go do something else :-)

> I see also
> "Atom Processors handle URIs."
> 
> "handle" is not an RFC 2119. It means that it's not even optional,  
> and not mandatory. Is it ok? Maybe "Atom Processors MUST handle URIs."?

Why is it not optional or mandatory? It's a declaration of something
that an Atom Processor does - I take it as being a "by definition",
with reference to earlier statements of RFC 2119 requirement in the
document.

(I think the earlier statement is in 4.2.7.1 where we find that
"processors MUST compare atom:id elements", knowing that (4.2.7) "[the
atom:id] content MUST be an IRI".)

Actually, since this is in the context of a security consideration,
it's not a restriction on the processors AT ALL. It's saying "since
Atom Processors are going to have to work with URIs/IRIs - they'll
have to handle them - implementors should consult RFC3986 and RFC3987
for security considerations in doing this".

> In the prose before it is said:
> "If the "src" attribute is present, Atom Processors MAY use the IRI  
> to retrieve the content. "
> 
> What is the behavior of the Atom processor when the MAY is not  
> implemented because it's optional and because it's not mandatory for  
> "Atom Processors" to handle URIs or IRIs.

If we assume, as is I think reasonable, that handling URIs/IRIs is
something that Atom Processors do by definition, then the last half of
that question isn't relevant.

The behaviour of the Atom processor when the MAY is not implemented is
that the Atom processor doesn't retrieve the content. So it doesn't
have the content, which it may not care about.

> >No consensus to make the schema normative. Everyone had a different
> >reason for opposing it, as I recall. :)
> 
> :)))
> no more feed validator then. :)

A feed validator doesn't have to use a schema, but it could use it for
a non-normative check ("you may have problems" - or even kicking i

Re: Review of Atom 0.8 Spec against W3C QA Specification Guidelines

[Karl Dubost]

Le 05-05-23 à 18:04, Robert Sayre a écrit :

Hi Karl. Thanks for the review. Some thoughts inline.


my pleasure


On 5/23/05, Karl Dubost <[EMAIL PROTECTED]> wrote:

Requirement 01: Include a conformance clause.


I tend to agree with Paul wrt conformance levels:
http://www.imc.org/atom-syntax/mail-archive/msg10296.html


:))) A conformance clause is helping you to do a bit more than the  
language used in the specification. RFC 2119 is a good choice to  
express the requirements of the specification. Nothing wrong with  
that. But it's a kind of hidden conformance layer and with a lot of  
regular different interpretation from the community. :)


Let's go a bit further though. Let's say I'm a developer who's  
creating an authoring tool for Atom, so more a producer than a  
consumer application.


"Atom Feed Documents"
"Atom Entry Documents"

I read "An Atom Entry Document represents exactly one Atom entry,  
outside of the context of an Atom feed. Its root is the atom:entry  
element."


Nowhere it is said that
"the root element of a conformant Atom Entry Document MUST be  
"atom:entry"."


What is a conformant Atom Authoring Tool?

The specification says at the start: "This specification describes  
conformance in terms of two artifacts; Atom Feed Documents and Atom  
Entry documents. Additionally, it places some requirements on Atom  
Processors."


If I read through the text "Atom Processors" are seen as consumers  
application, not producers. It means that all XSLTs, Web hosting  
services, etc can NOT claim conformance to Atom. :) I know it sounds  
strange. You can decide in the specification to forbid such a claim  
too, but at least it's better to be explicit than "obvious hidden  
meaning" which might be misinterpreted.



Requirement 06: Create conformance labels for each part of the
conformance model.
 NO. The conformance model being not completely clear. It's very
hard to know what are the different type of conformance and then to
put labels on them.



See comment #1.


I haven't taken the time :) to put the RFC 2119 together. It would  
help to understand

what are:
- conformant "Atom Entry Document"
- conformant "Atom Feed Document"
- conformant "Atom Processor"
(- conformant "Atom Producer")

An Atom feed s/validator/conformance checker/ is a processor, though  
it doesn't have to display or render the "Atom Feed Document". Will  
it be a problem with regards to the specification?


I see also
"Atom Processors handle URIs."

"handle" is not an RFC 2119. It means that it's not even optional,  
and not mandatory. Is it ok? Maybe "Atom Processors MUST handle URIs."?


In the prose before it is said:
"If the "src" attribute is present, Atom Processors MAY use the IRI  
to retrieve the content. "


What is the behavior of the Atom processor when the MAY is not  
implemented because it's optional and because it's not mandatory for  
"Atom Processors" to handle URIs or IRIs.



I'm not being picky, but just showing that a conformance model tries  
to tackle all these questions that might arise. It helps to really  
define how you implement the requirements of the specification.




No consensus to make the schema normative. Everyone had a different
reason for opposing it, as I recall. :)


:)))
no more feed validator then. :)


Hope it helps.

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

Re: extension elements inside link elements?

[Robert Sayre]

On 5/24/05, Paul Hoffman <[EMAIL PROTECTED]> wrote:
> 
> I read "empty" as "always empty", so the XML novice in me would say
> that the above expression in inherently wrong.

4.2.9 (editorial):  The atom:link element is explicitly described as
empty, which violates the rules in 6 for foreign element extension.
Remove "is an empty element that".

http://www.imc.org/atom-syntax/mail-archive/msg14365.html

Robert Sayre

Re: inheritance issues

[Thomas Broyer]

Antone Roundy wrote:
>
> On Tuesday, May 24, 2005, at 01:52  AM, Henry Story wrote:
>> Simplify, simplify. I am for removing all inheritance mechanisms...
>
> I would agree if we had a better way to avoid all the repetition that
> would lead to.  However, the only proposal[0] I can remember that would
> have done so has been rejected by the WG.  I'm torn on whether to bring
> this up (I'd like to see it done, but it's getting late), but looking
> at the reasons given for rejecting PacePersonRef [1][2][3], recent
> discussion of author, contributor and inheritance suggests that the
> opposition may have been mistaken.  See also [4].

I wasn't there at the time PacePersonRef was proposed. Here's what I'd
have said if I were:
-1 to dropping inheritance mechanism, this leads to repetitions of
atom:author and atom:contributor in each entry
+1 to id references as a way to allow "factorization" of people on one
place and thus saves some bytes by preventing the repetition of the Person
metadata (it might reveal even much better later when there will be
extensions to the Person constructs, e.g. FOAF, which might be quite
verbose). +0 on whether to use an atom:people container.

I'd way prefer clear and clean inheritance definition to repeating
metadata all the way down, even if the metadata uses references to
metadata elements defined elsewhere.

-- 
Thomas Broyer

Re: extension elements inside link elements?

[Paul Hoffman]

At 6:22 PM +1000 5/24/05, Eric Scheid wrote:

 > 4.2.9 The "atom:link" Element


 The "atom:link" element is an empty element that defines a reference from an
 entry or feed to a Web resource.


did we want to prevent expressions like this:






I read "empty" as "always empty", so the XML novice in me would say 
that the above expression in inherently wrong.


--Paul Hoffman, Director
--Internet Mail Consortium

Re: some small comments on 08

[Bill de hÓra]

Thomas Broyer wrote:


 * it is not less reliably implementable than the current draft's mandatory
   div element; if we go for a SHOULD or MAY on discarding the div elements,
   it is even *more* reliably implementable.


We had a discussion about optional div not so long ago, and I came away 
unconvinced then. Can you present some arguments to back those opinions up?


cheers
Bill

Re: inheritance issues

[Antone Roundy]

On Tuesday, May 24, 2005, at 01:52  AM, Henry Story wrote:

Simplify, simplify. I am for removing all inheritance mechanisms...


I would agree if we had a better way to avoid all the repetition that 
would lead to.  However, the only proposal[0] I can remember that would 
have done so has been rejected by the WG.  I'm torn on whether to bring 
this up (I'd like to see it done, but it's getting late), but looking 
at the reasons given for rejecting PacePersonRef [1][2][3], recent 
discussion of author, contributor and inheritance suggests that the 
opposition may have been mistaken.  See also [4].



Eric Scheid wrote:

oh darn. This damn inheritance stuff is nasty.


[0] http://www.intertwingly.net/wiki/pie/PacePersonRef
[1] http://www.imc.org/atom-syntax/mail-archive/msg09290.html
[2] http://www.imc.org/atom-syntax/mail-archive/msg09490.html
[3] http://www.imc.org/atom-syntax/mail-archive/msg11531.html
[4] http://www.imc.org/atom-syntax/mail-archive/msg11530.html

Re: some small comments on 08

[Thomas Broyer]

Thomas Broyer wrote:
> Graham wrote:
>> -1, and additionally I don't think the Pace is even complete or
>> reliably implementable.
>
> FYI, it is not,

Oops, before it'd be misinterpreted:
 * the Pace is not *complete*
 * it is not less reliably implementable than the current draft's mandatory
   div element; if we go for a SHOULD or MAY on discarding the div elements,
   it is even *more* reliably implementable.

-- 
Thomas Broyer

Re: some small comments on 08

[Thomas Broyer]

Asbjørn Ulsberg wrote:
> On Mon, 23 May 2005 08:54:32 +0200, Anne van Kesteren wrote:
 * 4.2.2 The "atom:category" Element
 Why is significant information hidden in attributes? That is bad for
 i18n and prevents people from defining the expansion of an
 abbreviation, for example.
>>>
>>>  Minor flaw. It happens.
>>
>> I think you are rushing things too fast. It would be much better if we
>> fixed this.
>
> I agree.

+1, drop the "label" attribute and make its value a child of the
atom:category element.

Some more wording would also be needed to explain the exact role of the
"term" attribute. Couldn't its value default to the "label" when not
present (this imply making it optional)?

  Can't we name them consistently? I'd suggest 'href' or 'url'.
>>>
>>>  Nope. Too late.
>>
>> And this.
>
> +2.

I have no opinion about atom:uri, it seems find to me but I'm not attached
to it.

@href gives an Hypertext REFerence to another, related, resource
(alternate, related, self, feed, etc.), so -1 to changing its name.

@src tells the Atom Processor where the content of the entry is located. I
wouldn't be opposed to "href" in this case, but nothing else than "href"
or "src".

Other listed examples were about attribute vs. text node, I'm +0.5 to
moving text nodes into attributes (in atom:logo and atom:icon)

These are also common usages in many XML dialects (XHTML, XInclude, XLink,
SVG, etc.) Many of these tend to use XLink when linking to or embedding
external resources, so using XLink wouldn't bother me either (hey, some
are talking about replacing atom:author|atom:contributor with Dublin Core,
so why not?)

-- 
Thomas Broyer

Re: some small comments on 08

[Thomas Broyer]

Graham wrote:
> On 24 May 2005, at 9:40 am, Henri Sivonen wrote:
>> On May 23, 2005, at 12:31, Julian Reschke wrote:
>>> For the record: I am +1 on >> PaceOptionalXhtmlDiv>.
>
> -1, and additionally I don't think the Pace is even complete or
> reliably implementable.

FYI, it is not, and I already explained in which extent (first, I forgot
to say in the Pace that the same would apply for atom:content with
type="xhtml"), that's why I pointed to a mail with some more explanation
[1]. I was told not to edit the Pace to reflect it, so...

[1] http://www.imc.org/atom-syntax/mail-archive/msg15320.html
-- 
Thomas Broyer

Re: Author and contributor

[Asbjørn Ulsberg]

On Mon, 23 May 2005 07:22:49 +0200, A. Pagaltzis <[EMAIL PROTECTED]> wrote:


• make atom:author plural
• keep atom:contributor
• punt bylines to an extension


It's the best suggestion made so far that has any potential of getting  
into the spec until christmas, so I'm +1 on this. :-)


--
Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/
«He's a loathsome offensive brute, yet I can't look away»

Re: The atom:uri element

[Asbjørn Ulsberg]

On Tue, 24 May 2005 14:40:41 +0200, Asbjørn Ulsberg  
<[EMAIL PROTECTED]> wrote:


Or is it so that the atom:uri element have many proponents on the list  
so it can't be renamed or changed to atom:link, atom:email or something  
[...]

  ^^
Just so the replies to this e-mail (if any) doesn't get concentrated  
around my little mishap with the elements here: I didn't mean writing  
'atom:email' there since we already have that element. The point I'm  
trying to make is not the name of the element, but rather its type. I'd  
like it to be constructed somewhat similar to atom:link, e.g. be an Atom  
Link Construct.


--
Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/
«He's a loathsome offensive brute, yet I can't look away»

Re: some small comments on 08

[Asbjørn Ulsberg]

On Mon, 23 May 2005 08:54:32 +0200, Anne van Kesteren  
<[EMAIL PROTECTED]> wrote:



* 4.2.2 The "atom:category" Element
Why is significant information hidden in attributes? That is bad
for i18n and prevents people from defining the expansion of an
abbreviation, for example.


 Minor flaw. It happens.


I think you are rushing things too fast. It would be much better if we
fixed this.


I agree.




 Can't we name them consistently? I'd suggest 'href' or 'url'.


 Nope. Too late.


And this.


+2.

--
Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/
«He's a loathsome offensive brute, yet I can't look away»

Re: inheritance issues (was: Author and contributor)

[Thomas Broyer]

A. Pagaltzis wrote:
> * Thomas Broyer [2005-05-24 09:05]:
>> c)
>> feed:
>>   author: A
>>   contributor: B
>>   entry:
>> contributor: C
[...]
>> c) The entry inherits the author but overrides the contributor. I'm
>>also open to considering it invalid.
[...]
> The rule you propose for contributor semi-inheritance is hard to
> explain clearly in prose and somewhat convoluted to implement in
> code though. And while I have not gotten around to learning RELAX
> NG, it also seems that it would be non-trivial to express as any
> form of grammar.
>
> After looking at all these cases, I would instead suggest that
> we prohibit atom:contributor in absence of an atom:author at the
> same level. That would make all of c), d) and e) invalid.
>
> Note that the semantics you propose for c), d) and e) are still
> expressible, they just require more repetition.
>
> Effectively, I am proposing:
>
> A non-empty set of atom:entry/atom:author overrides any set
> of atom:feed/atom:author and atom:feed/atom:contributor.
>
> atom:contributor may only appear if ../atom:author is also
> given.

If you just consider c) to be invalid, you can go with:

A non-empty set of both atom:entry/atom:author and
atom:entry/atom:contributor overrides any set of both
atom:feed/atom:author and atom:feed/atom:contributor.

or

If an atom:entry has neither an atom:author nor an atom:contributor
child element, the author(s) of and contributor(s) to the entry are
those specified at the feed level, that is, those appearing as children
of an atom:source or, if the atom:entry contains no atom:source child
element, those appearing as children of the atom:feed element.

Note that if an entry has no atom:author or atom:contributor child but
contains an atom:source child. If the atom:source element contains no
atom:author or atom:contributor child, the entry has no author or
contributor. In such a case, the atom:author and atom:contributor
children of the atom:feed element don't cascade into the atom:entry.

(and again, excuse me for my English, it's not my mother tong)

Actually, the proposed rule is the same as having an atom:person element
with a "role" property (attribute or child element) and a rule which says:

A non-empty set of atom:entry/atom:person overrides any set of
atom:feed/atom:person.

And you replace everywhere in spec "atom:author" with "atom:person with a
role equal to 'author'" and "atom:contributor" with "atom:person with a
role equal to 'contributor'".

Please note that I am not proposing changing atom:author and
atom:contributor to atom:person with a role property. This is just to make
clearer my proposal of "considering atom:author's and atom:contributor's"
as a whole, not atom:author's in one hand and atom:contributor's in the
other hand".

> That seems like it would isolate the specification of
> atom:contributor from any inheritance issues, whose discussion
> could be confined to the specification of atom:author.

We're talking about authors and contributors but inheritance is to be
explicitly defined for (copy)rights, categories, etC. as well.

> The only constellation that would have been possible with your
> proposed set of restrictions, which my set of restrictions no
> longer allow, is expressing that feed has only contributors, but
> no authors. If anyone feels that such feeds must be expressible,
> then the restrictions could be loosened so that only
> atom:entry/atom:contributor requires an ../atom:author; however,
> as long as noone feels that way, I suggest that the restriction
> be symmetric to simplify specification and implementation.

-0 to forbidding contributors without author at the feed level.

-- 
Thomas Broyer

The atom:uri element

[Asbjørn Ulsberg]

I've mentioned this several times before and haven't had time to follow  
the evolvement of the draft up until now, but as far as I can tell,  
atom:uri is still in place in the specification... Do we really need a  
pace to have that element renamed before the spec goes final?


Or is it so that the atom:uri element have many proponents on the list so  
it can't be renamed or changed to atom:link, atom:email or something  
making more sense? Even atom:iri is better at this point, imho.


--
Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/
«He's a loathsome offensive brute, yet I can't look away»

Re: Deterministic content models (conflict with Atom Publishing Protocol?)

[Thomas Broyer]

Norman Walsh wrote:
> Look at the content model for entry: it's a bag o' stuff some of which
> is required and some of which is optional (and optionally repeatable)
> and it's all allowed to occur in any order.
>
> I've forgotten the details of XSD's support for "&" content models, but
> I'm pretty sure that's beyond them.

>From "XML Schema Part 1 : Structures (Second Edition)", section "3.8.1 The
Model Group Schema Component" [1]:
"(all) contain all and only exactly zero or one of each element specified
in {particles}. The elements can occur in any order. In this case, to
reduce implementation complexity, {particles} is restricted to contain
local and top-level element declarations only, with {min occurs}=0 or 1,
{max occurs}=1."

[1] http://www.w3.org/TR/xmlschema-1/#Model_Group_details

-- 
Thomas Broyer

Re: Fetch me an author. Now, fetch me another author.

[Asbjørn Ulsberg]

On Sat, 21 May 2005 17:16:25 +0200, Eric Scheid  
<[EMAIL PROTECTED]> wrote:


what if  in that example was renamed to  (and specced to  
be something other than a Person Construct), and some mechanism  
introduced

to indicate the nature of the contribution by each of the s?


+1. This makes very much sense to me from a publishing company point of  
view.


--
Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/
«He's a loathsome offensive brute, yet I can't look away»

Re: Deterministic content models (conflict with Atom Publishing Protocol?)

[Norman Walsh]

/ Martin Duerst <[EMAIL PROTECTED]> was heard to say:
| If there is actual non-determinism now in the Atom core, that would be
| a reason for concern. If there is potential non-determinism in the

Look at the content model for entry: it's a bag o' stuff some of which
is required and some of which is optional (and optionally repeatable)
and it's all allowed to occur in any order.

I've forgotten the details of XSD's support for "&" content models,
but I'm pretty sure that's beyond them.

Be seeing you,
  norm

-- 
Norman Walsh <[EMAIL PROTECTED]> | We are more ready to try the untried
http://nwalsh.com/| when what we do is inconsequential.
  | Hence the fact that many inventions had
  | their birth as toys.--Eric Hoffer


pgpB4QHXvTIJl.pgp
Description: PGP signature

Re: some small comments on 08

[Graham]

On 24 May 2005, at 9:40 am, Henri Sivonen wrote:


On May 23, 2005, at 12:31, Julian Reschke wrote:


For the record: I am +1 on .


-1, and additionally I don't think the Pace is even complete or  
reliably implementable.


Graham

Re: some small comments on 08

[Henri Sivonen]

On May 23, 2005, at 12:31, Julian Reschke wrote:

For the record: I am +1 on 
.


+1 from me too.

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

Re: atom:source

[Graham]

On 24 May 2005, at 2:23 am, Robert Sayre wrote:

Disagree, the MAY is  about  putting atom:source in at all (yes, it's
possible to copy entries without using atom:source). The text implies
that the source must be an atom:feed element, and those have required
elements. The RNC also requires atom:title and atom:updated, etc. I
guess we could add "All required feed metadata elements MUST be
present". OK?


I think the thing it's missing is "All elements MUST be copied when  
creating an atom:source from an atom:feed"


Graham

Re: atom:type, xsl:output

[Graham]

On 24 May 2005, at 5:06 am, James Cerra wrote:


First off: it is an error to lie about your
media-type, so I would change "SHOULD be suitable for
handling as the indicated media type" to "MUST be
suitable for handling as the indicated media type."


+1


Secondly, XML may be entity (or CDATA) encoded like
@type="html" or plain xml like @type="xhtml".  This is
becuase of the "content of atom:content MAY include
child elements" phrase.  There is no guarantee if an
entity escaped passage is xml or a text node example
of an xml document (i.e. an example of an xml
document), for example.


If I follow you right, you misunderstand. Atom documents are  
unambiguous. XML has to be inserted literally, with no entity  
escaping (except for entities that are part of text nodes) allowed.








This is invalid, since it has no root element. It represents the  
standalone XML document:






This is correct:




Graham

extension elements inside link elements?

[Eric Scheid]

> 4.2.9 The "atom:link" Element
> 
> The "atom:link" element is an empty element that defines a reference from an
> entry or feed to a Web resource.

did we want to prevent expressions like this:





e.

Re: inheritance issues (was: Author and contributor)

[A. Pagaltzis]

* Thomas Broyer <[EMAIL PROTECTED]> [2005-05-24 09:05]:
> a)
> feed:
>   author: A
>   contributor: B
>   entry:
> no author not contributor
> 
> b)
> feed:
>   author: A
>   contributor: B
>   entry:
> author: C
> 
> c)
> feed:
>   author: A
>   contributor: B
>   entry:
> contributor: C
> 
> d)
> feed:
>   contributor: A
>   entry:
> author: B
> contributor: C
> 
> e)
> feed:
>   contributor: A
>   entry:
> author: B
> 
> a) The entry inherits both the author and contributor from the feed.
> b) The entry inherits nothing from the feed.
> c) The entry inherits the author but overrides the contributor. I'm
>also open to considering it invalid.
> d) The entry inherits nothing from the feed.
> e) The entry inherits nothing from the feed.
> 
> Let's see what others have to say about this and then find the
> appropriate wording.

Thanks for taking the time to spell out combinations; good food
for thought. You are right that the entry in a) not inheriting
contributors, as per my proposed rules, would be counterintuitive.

The rule you propose for contributor semi-inheritance is hard to
explain clearly in prose and somewhat convoluted to implement in
code though. And while I have not gotten around to learning RELAX
NG, it also seems that it would be non-trivial to express as any
form of grammar.

After looking at all these cases, I would instead suggest that
we prohibit atom:contributor in absence of an atom:author at the
same level. That would make all of c), d) and e) invalid.

Note that the semantics you propose for c), d) and e) are still
expressible, they just require more repetition.

Effectively, I am proposing:

A non-empty set of atom:entry/atom:author overrides any set
of atom:feed/atom:author and atom:feed/atom:contributor.

atom:contributor may only appear if ../atom:author is also
given.

That seems like it would isolate the specification of
atom:contributor from any inheritance issues, whose discussion
could be confined to the specification of atom:author.

The only constellation that would have been possible with your
proposed set of restrictions, which my set of restrictions no
longer allow, is expressing that feed has only contributors, but
no authors. If anyone feels that such feeds must be expressible,
then the restrictions could be loosened so that only
atom:entry/atom:contributor requires an ../atom:author; however,
as long as noone feels that way, I suggest that the restriction
be symmetric to simplify specification and implementation.

Regards,
-- 
Aristotle

Re: atom:type, xsl:output

[A. Pagaltzis]

* James Cerra <[EMAIL PROTECTED]> [2005-05-24 06:35]:
> > > XML 1.1
> > 
> > Not supported.
> 
> I'm confused.  There is nothing inherent in the spec that
> prevents XML 1.1 or any future versions from being supported.
> And why introduce incompatibilities in atom:content that also
> bork with arbitrary XML 1.0 documents too?  I assert this,
> because the spec says in section 4.1.3.3, "Processing Model,"
> that:

You can only embed XML 1.1 documents directly into another
document if that document is also XML 1.1. (Note that I am not
talking about transporting XML 1.1 documents as an opaque
serialized string.)

Embedding XML 1.1 documents inside an XML 1.0 document is not
possible, because
• XML 1.1 allows control characters to be included as entities
  which XML 1.0 forbids in any form,
• an XML 1.0 processor will not understand an embedded XML 1.1
  document,
• etc.

> ] 4.  If the value of "type" ends with "+xml" or "/xml"
> ] (case-insensitive), the content of atom:content MAY
> ] include child elements, and SHOULD be suitable for
> ] handling as the indicated media type.  If the "src"
> ] attribute is not provided, this would normally mean that
> ] the "atom:content" element would contain a single child
> ] element which would serve as the root element of the XML
> ] document of the indicated type.
> 
> First off: it is an error to lie about your media-type, so I
> would change "SHOULD be suitable for handling as the indicated
> media type" to "MUST be suitable for handling as the indicated
> media type."

An Atom processor does not know whether the embedded XML document
is a valid document of the given type. Only an attached processor
for the given document type will be able to decide. As such, the
validity of the Atom feed document is not affected by the media
type. It will, of course, cause interop problems if you lie about
the media type, hence SHOULD.

> Secondly, XML may be entity (or CDATA) encoded like
> @type="html" or plain xml like @type="xhtml".  This is becuase
> of the "content of atom:content MAY include child elements"
> phrase.  There is no guarantee if an entity escaped passage is
> xml or a text node example of an xml document (i.e. an example
> of an xml document), for example.

No. Wrong.

There is nothing saying that the content of atom:content MAY be a
text node. It MAY only be a child element.

If there is no child element, @src must be set, ie the XML
document constituting the content is external to the feed.

I will say, though, the the spec could stand to be more explicit
in this instance.

Regards,
-- 
Aristotle

Re: inheritance issues

[Henry Story]

Simplify, simplify. I am for removing all inheritance mechanisms...

Henry

On 24 May 2005, at 02:02, Bill de hÓra wrote:

Eric Scheid wrote:

oh darn. This damn inheritance stuff is nasty.



Inheritance suggests a programming model to allow the evaluator to  
be coded for it. It's rarely as simple as it looks to define a  
decent model that does what people think it does at first glance.  
As things stand, it will be an immense coincidence if we do not end  
up dishing out nasty surprises for users. Atom's just not a very  
good programming language ;)


cheers
Bill

Re: inheritance issues (was: Author and contributor)

[Thomas Broyer]

A. Pagaltzis wrote:
>
> * Eric Scheid <[EMAIL PROTECTED]> [2005-05-24 01:40]:
>> Consider too a feed which has both authors and contributors at
>> the feed level, an entry with neither authors or contributors
>> (simple case of inheritance), and another entry with a single
>> author and no contributors (does the entry inherit the feed
>> contributors?), and a third entry with no specified author
>> (inherits, right?), but with contributors (no inheritance,
>> right?).
>>
>> The first case is easy to guess the intention. The third case
>> is easy to guess the intention. It's the second case which is
>> the beotch.
>
> I think of these things in terms of what is possible to express.
>
> a) Any entry always has an author.

Right, I forgot that.

Actually, I was reading the format-08 "inlined" RNC, which doesn't include
the schematron rules.
Could there be some "improvement" to the spec?

> b) A feed may or may not have an author.
> c) An entry may or may not have contributors.
> d) A feed may or may not have contributors.
>
> Any solution must not prevent any of these from being
> expressible.
>
> I already discussed why replacement is preferrable to merging
> when any of these are given at both the feed and entry level.
>
> Now with that in mind, c) and d) suggest to me that
> atom:feed/atom:contributor never inherits to entries. If entries
> were to inherit from the feed, then in a feed with contributors
> it is not possible to express that an entry had no contributors.

Not if you consider the "group" formed by the authors and contributors.
Hmm, what about that: feed level contributors cascade to the entry level
only when there is an atom:author element at the feed level which also
cascades. Er, I might be not quite clear, so let's see examples: how would
you interpret the following?

a)
feed:
  author: A
  contributor: B
  entry:
no author not contributor

b)
feed:
  author: A
  contributor: B
  entry:
author: C

c)
feed:
  author: A
  contributor: B
  entry:
contributor: C

d)
feed:
  contributor: A
  entry:
author: B
contributor: C

e)
feed:
  contributor: A
  entry:
author: B

Other cases don't have any problem (or I missed it) or are invalid (e.g.
no author at all)


a) The entry inherits both the author and contributor from the feed.
b) The entry inherits nothing from the feed.
c) The entry inherits the author but overrides the contributor. I'm
   also open to considering it invalid.
d) The entry inherits nothing from the feed.
e) The entry inherits nothing from the feed.

Let's see what others have to say about this and then find the appropriate
wording.

> So in summary:
>
> The set of atom:entry/atom:author overrides the set of
> atom:feed/atom:author for a particular entry, should the set
> be non-empty. [Inheritance with replacement semantics.]
>
> The set of atom:feed/atom:contributor applies only to the
> feed and not to any of its entries. [No inheritance.]

I'm not opposed to that but it might not be obvious in the a) example above.

-- 
Thomas Broyer