Henri Sivonen, > > MSIE conditional comments. See other person's reply. > > I thought they were for text/html tag soup only. Anyway, I think Atom > should not try to enable such bogosity in XML.
I don't think Atom should take a position if it doesn't have to. > > And yes: I know that Atom is not FTP or HTTP. I'm looking at the Atom > > entry > > uploader's POV rather than the downloader's perspective. The Atom API > > is a way > > to simplify managing web sites: > > Is it really? Straight bytes over HTTP PUT seems a lot simpler to me > than Base64 in an XML envelope over HTTP PUT. In this case, the simplier grammar option is a more complex job. First, Atom already supports this with every other MIME type including HTML, but not anything that is XML. Why? Second, if your content is a literal document of *any* type then: ** steps with envelope ** 1. PUT doc-with-envelope.atom to http://uri1.com. 2. PUT doc-with-envelope.atom to http://uri2.com with user, pass. ** steps without envelope ** 1. PUT doc-referencing-uri1.atom to http://uri1.com. 2. PUT image.png to http://uri1.com/images/image.png. 3. Modify doc-referencing-uri1.atom to reference uri2. 4. PUT doc-referencing-uri2.atom to http://uri2.com with user, pass. 5. PUT image.png to http://uri2.com/_title_of_entry_/image.png with user, pass. That is, including it in an atom:content element and sending that off to the server allows you to send that off to another server with ***only changing the Atom document's PUT uri*** rather than sending the external document according to each server's implementation (i.e. uri or other means). Having a standard way of sending files for a blog - like a picture blog for instance - is really nice. Otherwise it is much harder to change servers or atom processors. > >> Vanilla XML processors don't act on PIs. They report them to the > >> application--in this case the Atom processor. > > > > So Atom Processors MUST be between any XML and PI processor stages? > > That > > sucks! It means just to display Atom, I can't use a generic XSLT > > processor > > like Saxon or MSIE. > > What PIs do they act on besides the style sheet PI, which must appear > in the prolog (so conforming tools should not act on it if it appears > within atom:content)? You are correct about <?xml-stylesheet?> but in general there could be others. XSLT stylesheets can use them for flexibility, for example. Better not to make assumptions about their behavior. > >> Depending on an entity reference and not being able to accept the > >> straight replacement text is just wrong. > > > > I agree. I'm just bringing up possible incompatibilities for debate! > > I don't think that's an incompatibility that deserves catering for. Why not? Why be incompatible for the sake of incompatibility? That's just asking for trouble when Atom is used in ways not originally envisioned (and there always are). > >> That's a non-issue. You don't just throw away the DOCTYPE but parse > >> the > >> original document with it and reserialize as a DOCTYPEless fragment. > >> You don't lose well-formedness or content. You only lose the shallow > >> attribute data typing provided by the DTD. > > > > Well, that data could be valuable. > > IDness is. For practical purposes, the other stuff is not. There are > other solutions for IDness. I don't understand why? > > With DOCTYPE information associated with embedded content, it becomes > > possible to > > transform entries into valid XML or HTML documents. > > What do you need valid documents for if the validity is just an > property internal to the document? That is, the document is valid > according to its own rules as opposed to conforming to the rules > required by some downstream software. Valid as in, this is valid HTML 3.2 or that is valid HTML 5 or this is valid HTML 4.01 transitional. Right now it is impossible to specify that for atom:[EMAIL PROTECTED]"html"] content, but that doctype information is esssencial for properly interpreting the semantics of the HTML content, and possibly how to write it out as a web page. :-( If you make me guessing I'll go mad! :-) > > Some apps change their behavior with well-formed and valid modes. > > That seems like a bad idea. Can you give examples? > > > DOCTYPE switching may be evil, but it is currently a necessary evil. > > It is not a necessary evil for XML. I am strongly against any Atom > feature motivated by or designed for enabling and/or encouraging > doctype sniffing in XML. > > Please see http://hsivonen.iki.fi/doctype/#xml See reply immediately above. HTML currently uses doctypes for switching between versions of the langauage. There is no other way to properly interpret content without guessing in the current drafts. That is a worse sin inflicted upon programmers, than allowing the subset that do rendering to do naughty DOCTYPE sniffing. > > I see this as low risk (it doesn't break anything and could even be an > > OPTIONAL feature) > > Optional features always have a cost. Also, they tend to become de > facto mandatory for everyone or de facto useless for everyone. Yes, but this is a low cost as long as the semantics of having the doctype specified and not having it specified are clearly stated. The cost of not including it is having implementions differing on how they interpret the xml. The result is that people will become locked into particular atom processors and the practical spec will diverge from the standard. That would be a failure of Atom. > Base64 XML in XML was rejected earlier in the working group process. It is in the latest public draft that I read. What is replacing it? > > No, any well formed XML processor MUST expand internal entities and add > > replaced attributes as well. This is NOT OPTIONAL. > > So is expat non-conforming? If it doesn't, then it is non-conforming. That's how non-validating XML processors are defined by the spec. I quote from section 5.1 paragraph 4: [Definition: While they are not required to check the document for validity, they are REQUIRED to process all the declarations they read in the internal DTD subset and in any parameter entity that they read, up to the first reference to a parameter entity that they do not read; that is to say, they MUST use the information in those declarations to normalize attribute values, include the replacement text of internal entities, and supply default attribute values.] There is no room for any other interpretation, I think. > >> Atom is not claiming that you could embed the literal source of any > >> XML > >> doc. You can embed the stuff that canonicalization would preserve. > > > > Yet you can do that with PNG, PDF, or other content via base 64 > > encodings. It > > is silly to allow that for them and not XML. > > Looks like straight HTTP without an Atom envelope in between suits your > needs better. It is inflexible working at such low protocols; you should not need WS-* or a standard REST format (and I know of no way to specify REST URIs/requests in a standard format anyway) to switch between blogging servers/clients. See second reply. -- Jimmy Cerra https://nemo.dev.java.net __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new Resources site http://smallbusiness.yahoo.com/resources/
