Welcome ;)
With the caveat that I'm not an i18n expert; what do you mean by
'different location'? IRIs don't have a separate level of %-encoding on
top of that used by URIs; rather, as I understand it, they leverage the
URI %-encoding mechanism, by just standardising on UTF-8 for the
character
In my experience, "media type" is colloquially used to mean the
type/subtype construct, without parameters; a particular context
specifies whether parameters is allowed (e.g., Content-Type). That
said, it's not clear in the specs; there is no ABNF rule or even terms
that I can find that we coul
Oops; I meant draft-freed-media-type-reg.
On Apr 6, 2005, at 5:13 PM, Mark Nottingham wrote:
Section 4: RFC 2045 is referenced. 2045 is on its way to being
obsoleted by
draft-freed-mime-p4 (in the RFC Editor queue) and
draft-freed-media-type-reg
(in last call). Can the more recent documents be
OK, first-time poster :)
I was just thinking about IRIs recently and thought about a possible
source of ambiguousness. If the URI element can be EITHER an IRI or a
URI, then:
http://example.com/200%25equalsZero
This is both a valid IRI and a valid URI, but if it is considered to
be an IRI it wi
The "type" attribute of atom:content can be a MIME media type:
> 4.1.3 The "atom:content" Element
[...]
> 4.1.3.1 The "type" attribute
[...]
> [...] Failing that, it MUST be a MIME media type [RFC2045] with a
> discrete top-level type (see Section 5 of [RFC2045]).
After looking at RFC2045, I
/ Anne van Kesteren <[EMAIL PROTECTED]> was heard to say:
| Norman Walsh wrote:
|> But I hope not. I don't really want to have to rev the Atom format
|> spec when XHTML 2.0 comes out. With care, I want to just put XHTML 2.0
|> stuff in my xhtml:div elements and let the down-stream appliation work
|
Anne van Kesteren wrote:
Norman Walsh wrote:
But I hope not. I don't really want to have to rev the Atom format
spec when XHTML 2.0 comes out. With care, I want to just put XHTML 2.0
stuff in my xhtml:div elements and let the down-stream appliation work
it out.
XHTML 2 does have a different namesp
Mark Nottingham wrote:
Hmm. As far as I can tell, the *only* place where we actually define a
rule is 4.2.9.2, and that's just combining two rules by reference. I
wonder if we can save complexity here (and remove one normative
reference) by just doing this in prose; the text is currently:
[[[
Norman Walsh wrote:
But I hope not. I don't really want to have to rev the Atom format
spec when XHTML 2.0 comes out. With care, I want to just put XHTML 2.0
stuff in my xhtml:div elements and let the down-stream appliation work
it out.
XHTML 2 does have a different namespace. Future versions of XH
On Apr 11, 2005 3:23 PM, Norman Walsh <[EMAIL PROTECTED]> wrote:
> I don't really want to have to rev the Atom format
> spec when XHTML 2.0 comes out.
+1
-joe
--
Joe Gregoriohttp://bitworking.org
[ discussion of basic vs. strict and validity wrt xhtml/html elided ]
| >I'd propose to go back to XHTML 1.0 "Strict" instead.
|
| Very good point. A very strong +1.
Do we really want to go here? I hadn't interpreted the Atom format
spec as requiring that the content of the xhtml:div be valid acc
Does anybody have feedback on the suggestions/questions below?
If I don't get any feedback on the ABNF or validity discussions, I'll
proceed as outlined. I think there needs to be *some* feedback
regarding the link relation registry; I'm proposing substantial changes
there (my preferred approach
12 matches
Mail list logo
