Henri Sivonen, > > If the intended Atom content contains essential comments, > > There should be no such thing as essential comments. The XML spec does > not require XML processors to report comments to the app. Hence, > comments are inappropriate for transferring essential data.
Yes, but MSIE^H^H^H^Hsome xml processors (cough cough) still inappropriately use comments for that purpose. Then there are example XML documents (i.e. for tutorials) that sometimes require comments be preserved. So although it is not required by XML processors, it is nice to not introduce incompatibility with that optional part of the spec. Finally if you are posting content associated with an entry with the Atom API, then it is important that any documents uploaded are not modified. (Besides at worst this is a non-issue if no comments are ever essential.) > > processing instructions, > > These could be supported in embedded content if the Atom spec said PIs > in atom:content belong in content and should not be acted upon by the > Atom processor. I don't like this condition. Any content will be read by XML processors before being handed to an Atom processor. So the generic XML processor will not be able to differentiate between PIs that are significant - and thus should be processed by their processors - from those which should be passed through. > > entities > > Entities can be flattened. Again, as with comments, I agree in principle, but in practice some processors depend on them. > > DOCTYPE declaration(s) > > If DOCTYPE is essential for the receiving app, you've got bigger > problems than Atom. Hardwiring IDness based on namespaces is more > practical than relying on DTD-based data typing. I'm not necessarily talking about external document type definitions. Preventing DOCTYPEs would cause incompatibilities with XML well-formedness processing. From the spec: "[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.]" Some RDF/XML processors already put internal DOCTYPE declarations to make the content more readable. There is nothing intrinsically bad about DOCTYPE sections, they provide hints to validating XML processors about validity and can save time, space, and increase readability. Remember that anything compatible with XML MUST allow its optional features to be in the markup (even if they are just ignored). So if you disallow DOCTYPE sections, then you can't claim to support XML. Anything that could have any chance of dataloss - in this case, the loss of XML comments, PIs, and XML and DOCTYPE declarations � is bad. Your comment is a good design pattern for XML based specifications, but in general they don't have to follow that rule of thumb. Besides, I don't want the implementors to get any bad ideas so explicitly stating these things disenfranchises that behavior from being acceptable from the beginning. -- Jimmy Cerra https://nemo.dev.java.net __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new Resources site http://smallbusiness.yahoo.com/resources/
