[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [opendocument-users] RE: Foreign elements and attributes
2009/3/4 Dennis E. Hamilton <dennis.hamilton@acm.org>: > The following remarks are all speculative, because we don't know whether > anyone will stub their toe on these or not. A little Dennis, just a little :-) > ANALYSIS > ======== > > 1. We still have a problem with foreign attribute values on existing > attributes. When such an attribute has no default value (the defined > fall-back) and the attribute is required, the document would be > unacceptable. I don't think your proposal addresses this case anyhow, but I > do notice that language being introduced for it has this hole. I also note > that those places, such as table:formula, where all of the values are > foreign in ODF 1.1 [and presumably still permitted in ODF 1.2 (extended) > documents], the fallback from only one something to only nothing is pretty > stark. As a generality, I'm not in favour of backwards compatibility. I'd suggest 1.1 'extensions' be treated as any other 'extension' > > 2. One problem with the use of attributes only is that there can only be one > occurrence of an attribute of the same name per element. There is no > provision for multiplicity, repetition, etc. Same local-name, different namespace? Are they 'different'? > > 3. One way to deal with situations like (2) is to use the ODF counterparts > of <div> and <span> or (hack, cough) the ODF bookmark provisions that allow > hierarchy to be transcended in the manner exploited by the RDF Metadata > feature. Scenario. You are an implementor. You come across a valid ODF element with foo:bar="The quick brown fox" as an attribute. Would it make sense to treat this as content? I don't think so. I'd suggest as a 'maximum', the presentation layer is asked to inform the reader that such foreign content exist. More practically, as a document, report that it contains an extension and leave it at that. > > 4. I said this is all speculative, because we don't know whose situation > would be thwarted by the constriction. The only applications that can reasonably process extensions are those that comprehend the element/attribute/namespace combinations, probably because that application generates them. That makes sense, in a local, non conformant usage which I see as doing no harm when used in that way. That's how good features can be trialled for adoption by the standard. regards -- Dave Pawson XSLT XSL-FO FAQ. Docbook FAQ. http://www.dpawson.co.uk
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]