[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [office-comment] ODF security hazard? (ODF all versions)
Dennis hi > I think banning <!DOCTYPE > is a little harsh and one might rather > address the specific problem (reliance on external entities). Being > able to define character entities is actually very handy, and rather > applicable in those places where ODF tends to be HTML-ish If such a document was edited and re-saved, would the emitted instance preserve the entity declarations/references? I think if entities are really allowed (to which my initial reaction is: yikes), then there needs to be some clear statements about how an ODF processor would handle them. > I'm wondering whether it is permissible for <!DOCTYPE>-included URIs > to relatively refer within the package itself, Constraining references is another interesting idea - something that could be expressed perhaps in this (yet-to-be-invented) feature validation language I mentioned ... > at the moment, all XML 1.0 > edge/outlier > cases have to be tolerated (e.g., charsets, parameters, prolog > omission, MIME Type interaction, entity definitions, DTD occurrences, > processing instructions, and for all I know, byte-order marks). Yes, and some of these could be very useful (processing instructions for recording application-specific incidentals, for example). > PS: I don't know that anyone on the ODF TC has noticed that there is a > landmine in the latest XML 1.0 edition, having to do with the expanded > character set (well, code points) that must be tolerated in NCNames, > IDs, IDREFs, IDREFS[s] and that these are also submarined in by some > clever adjustment to URLs that are cross-referenced from the Namespace > specification and in some links in older editions of XML 1.0. They > apply to xml:id too, of course. Are you testing us about that in the > comment at > <http://lists.oasis-open.org/archives/office- > comment/200902/msg00009.html>? Yes. Well, perhaps not "testing" but hoping for some guidance :-) This is a tremendous problem for nearly all SC 34 standards. I'm hoping SC 34 will come up with a policy on how to handle the 5th edition. My slight preference at the moment is to specify 4th edition for everything and acknowledge that with that edition, XML 1.0 development effectively ceased. But since 5th edition is notionally helpful for Asian users, that isn't a totally satisfactory solution for an International organisation. What happened at the W3C here (and with XML 1.1) makes an interesting case study in the intersections between versioning, interoperability, conformance and adoption .... - Alex.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]