- From: Ian Hickson <ian@hixie.ch>
- Date: Wed, 31 Dec 2008 01:21:52 +0000 (UTC)
- To: Elliotte Harold <elharo@metalab.unc.edu>
- Cc: "www-tag@w3.org" <www-tag@w3.org>
On Tue, 30 Dec 2008, Elliotte Harold wrote: > > I definitely believe that defining syntax, semantics, and behavior in > one spec is a very bad idea. The only example I can think of where the syntax, semantics, and behaviour were defined in _different_ specs was the OWL specs, and my understanding is that that working group concluded it was a mistake. Personally I think the spec structure used by SVG, CSS, HTML4, HTTP 1.1, XML, XMLNS, etc, is fine, we just need more detail throughout. > > To use XML as an example -- XML doesn't actually define how to parse > > XML, and thus there is no concept of the processing of an end tag, > > which then makes it very hard to define things such as > > document.write(), SVGLoad events, <script> processing, etc, in > > languages that use XML. > > That's a feature, not a bug. Different systems will have different needs > for processing. The weakness of the XML spec is that it actually does > define a little more processing than it needs to or should. It would be > a stronger spec had it limited itself to the definition of what a > well-formed document is. It is quite possible to provide for the different needs for processing while still being detailed enough to ensure uniformity across all applications. I agree that flexibility is a feature. But when the flexibility comes at the cost of the spec being so vague as to _prevent_ uniformity in implementations, then it is a bug. > > It also doesn't define the error handling for incorrect values on the > > xml:space attribute. > > Yes, that's a bit of a weird corner case. Applications are free to treat > that as an error or not as they see fit. However that's reasonable given > that most applications don't really care about xml:space at all. If most applications don't care, then maybe the feature shouldn't exist, or should be defined in a separate specification (like xml:id). Just because most implementations don't need the feature, and will do nothing with the feature, does not mean that those implementations that _do_ need the feature shouldn't have an unambiguous specification of what the feature does and how to process it. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 31 December 2008 01:22:27 UTC