nk you're proposing).
James
--
/------\
James Aylett xapian.org
[EMAIL PROTECTED] uncertaintydivision.org
checked again, and all is well.
Cheers,
James
--
/----------\
James Aylett xapian.org
[EMAIL PROTECTED] uncertaintydivision.org
bly the former).
Well, it's a private extension, so in practice you're not going to
know if we define it or not :-)
But yeah, point taken and I'll make sure it gets added to our spec
internally.
James
--
/--\
J
;player' for the atom feeds involved, and some clients want a
title alongside the feed icon and/or logo.
Feed Validator gets upset with extension attributes - is it wrong?
James
--
/----
wn which we can decorate with
titles, languages and whatever to our heart's content, even though
it's redundant to some extent?
James
--
/------\
James Aylett
other hand, a way of subscribing to one feed that sometimes
publishes in both English and (say) French, and only reading one
translation of each would be handy. That's probably rel='alternate'
within the atom:entry, though.
James
--
/----
nguage=... parameter to the type, but no such
parameter exists. (And people might laugh at
language=x-piratical-aaargh ... not to mention argue about the number
of 'a's required :-)
James
--
/----
t. After all, someone can still subscribe their reader directly to
the feed.
I don't think we need this (but I still like the use case :-).
James
--
/------\
James Aylett
ignificant), after all.
James
--
/------\
James Aylett xapian.org
[EMAIL PROTECTED] uncertaintydivision.org
spell out what Atom consumers should do if they encounter a
Date construct with "Last Thursday" in, either. Pointing out the
common error AS AN ERROR should be sufficient IMHO.
J
--
/-
ach is - it all
depends on what you're trying to do.
James
--
/------\
James Aylett xapian.org
[EMAIL PROTECTED] uncertaintydivision.org
he source of the match). This isn't nearly so important,
though, and I'm quite willing to accept the shmershing together of the
ideas. (Or even that I'm wrong.)
James
--
/--\
James Aylett xapian.org
[EMAIL PROTECTED] uncertaintydivision.org
nal to the OpenSearch issue, but if
people are interested in discussing a richer search extension we can
try to clear some time to pull it into shape.
[1] <http://xapian.org/>
James
--
/----------\
James Aylett
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 Pro
at 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.
James
--
/--\
James Aylett xapian.org
[EMAIL PROTECTED] uncertaintydivision.org
nd two fathers" strongly suggests, to me at least, that they are
distinct sets.)
James
--
/--\
James Aylett xapian.org
[EMAIL PROTECTED] uncertaintydivision.org
t religious about this particular issue, and I'm +1 on
the latest PaceClarifyAuthorContributor. I think we still need a
clarification along the lines of what danbri suggested, to make things
as obvious as possible.
James
--
/---
se me any problems, providing (as danbri says) that
the spec makes it clear that we're not imposing these
restrictions. Let the publishers decide what to say (because they will
anyway, even if only in 0.001% of the cases and by mistake in an
undetectable way).
James
--
/--\
James Aylett xapian.org
[EMAIL PROTECTED] uncertaintydivision.org
tions is
> about a different entity" would be plenty.
I'd be happy with that (particularly as the concept, but I'm happy
with it textually as well).
James
--
/------\
James Aylett
tion is to disallow "James Aylett" as both contributor
and author, I'm -0 (at least, possibly +0). If your intention is to
disallow "James Aylett and James Lark" as authors, and "James Aylett"
as contributor (with "James Lark" as a second contributor) then I
e precise about
what the semantics are without this rule, IMHO.
James
--
/------\
James Aylett xapian.org
[EMAIL PROTECTED] uncertaintydivision.org
ntical textual strings? Seems an arbitrary non-technical
semantic to me.
James
--
/------\
James Aylett xapian.org
[EMAIL PROTECTED] uncertaintydivision.org
ut resorting to fuzzy matching? I thought we???d
> gone over this.
I think we're trying to do too much here. Why on earth are we
disallowing a list of authors that includes the same person twice?
Why does it actually cause problems? I can write the following English
sentence:
"The boo
+.5 from me
+1, +.5, +.5 from me.
James
--
/------\
James Aylett xapian.org
[EMAIL PROTECTED] uncertaintydivision.org
if necessary).
So I'm actually +0, I guess.
James
--
/------\
James Aylett xapian.org
[EMAIL PROTECTED] uncertaintydivision.org
doesn't make sense
logically, it seems the only viable tradeoff that has any real
utility.
James
--
/--\
James Aylett xapian.org
[EMAIL PROTECTED] uncertaintydivision.org
Derivatives,
Non-Commercial'" and pointing to the CC URI is fine, but saying
"follow this URI for rights info" and nothing else isn't.
I'm concerned that making an explicit URI part of the right elements
would encourage people to shift the bal
lients to check it for the next x minutes.
Indeed - Expires doesn't say it won't change, it says that you
shouldn't care whether it's changed.
James
--
/------\
James Aylett
ffected by it (by writing server
components) is pretty small.
James
--
/------\
James Aylett xapian.org
[EMAIL PROTECTED] uncertaintydivision.org
Not sure if anyone's pointed this out. Section 4.2.9.2 (the "rel"
Attribute), second paragraph:
> The value of "rel" MUST be string ...
which should probably be "... MUST be a string ...".
James
--
/----
pointed out, even if you do book against raw
click volumes, your only way of figuring out whether this was the best
value you could have made out of your property is to calculate the
clickthrough rate, which requires some measure of per-media recording.
James
--
/-----
On Mon, May 02, 2005 at 06:34:44PM +0200, Anne van Kesteren wrote:
> James Aylett wrote:
> >(Assuming is an acceptable root element for SVG.)
>
> It isn't. application/xml is probably more appropriate.
It would be, if SVG explained how to embed fragments in other XML
diale
cceptable root element for SVG.)
James
--
/----------\
James Aylett xapian.org
[EMAIL PROTECTED] uncertaintydivision.org
.
So yes, Eric is right that they don't care about the ord value. Note
however that it's also possible to track other things through DCLK
(and other ad industry) tags, and the tag might be generated on the
fly based on all sorts of things that they sometimes
s a MIME media type
> [RFC2045] and does not begin with "text/" nor end with "+xml".
James
--
/--\
James Aylett xapian.org
[EMAIL PROTECTED] uncertaintydivision.org
>
> Wouldn't be more readable, in my eyes.
OTOH since someone has asked the question who presumably is fairly
knowledgable about XML, and most people people are not, would it be
worth putting a brief comment pointing to the appropriate section of
the XML TR?
"Note that in XM
er than a
subjective call. As such, I don't see the value of making it a MUST -
forcing to export their opinions isn't /always/ the purpose of a blog
format :-)
James
--
/-
+1
James
--
/--\
James Aylett xapian.org
[EMAIL PROTECTED] uncertaintydivision.org
ent with a non-HTML
version. (Something which I believe can't be done legally with RSS, or
at least not all the different breeds. Not that that matters.)
James
--
/--\
James Aylett xapian.org
[EMAIL PROTECTED] uncertaintydivision.org
oducers would be helpful.
James
--
/------\
James Aylett xapian.org
[EMAIL PROTECTED] uncertaintydivision.org
portant representation. From its
point of view, it is - and this is its metadata.
> PS. grammarians might want to tell me of it is "of which" or "for
> which".
I think it's "of which". It's clear either way, though, which is the
important thing :)
Ja
other?
Of 1c, there will be a small number of
tools-that-have-yet-to-be-written where strong suggestions in the spec
would lead to the authors instead choosing 1d. The rest we're going to
have to live with, somehow.
James
--
/---
eeds to be made clear, or at the very least unambiguously
decipherable from the spec.)
James
--
/------\
James Aylett xapian.org
[EMAIL PROTECTED] uncertaintydivision.org
43 matches
Mail list logo
