- From: Lachlan Hunt <lachlan.hunt@lachy.id.au>
- Date: Wed, 20 Jan 2010 23:41:50 +0100
- To: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Cc: "public-html@w3.org" <public-html@w3.org>
Leif Halvard Silli wrote: > It would be interesting if you can point to other _specification_ > extension points which also results in documents that get a valid > stamp. It's not clear to me what you mean by "valid stamp" in this case. Are you referring to the concept of conformance/validity, or do you mean the stamp of approval issued by a validator, which would be inherently limited in the vocabularies that it supports? > I meant: a policy which says that "applicable specification" is the > only _specification_ extension point makes it difficult to use a > validator as a development tool. When I say "development tool" then I > still meant the W3 validator - not some private validator. For HTML5, the W3C's validator uses a copy of the validator that Henri has developed for validator.nu. Are you referring to validator.nu as "some private validator", despite it using the same codebase as the W3C's validator? > My primary point is about @profile: I don't expect that validators > should be able to know - and thus perform validation - of all possible > profiles, but I expect that they should not consider that I have made a > suspicious document just because I used @profile. When I use @profile, > then I am open about the semantics I use. I wonder why that should be > punished. It is really not clear to me what the perceived benefit is that you believe is gained by using profile. Can you explain exactly how you expect it to be utilised by any implementations, and why that would be useful? >> In case it is a personal "you": Validator.nu allows its built-in >> features to be replaced piecewise with custom schemas. That is, you >> could feed Validator.nu your own RELAX NG schema and still use the >> built-in table integrity checker, for example. The particular >> validator extension mechanisms supported by Validator.nu at a given >> point in time aren't (and, in my opinion shouldn't be) coupled with >> the spec extension mechanisms of the HTML5 spec. > > It is of course nice if I can do this offline on my own computer. But > if I want to validate a document which does use an attribute or element > that the HTML5 language specification doesn't contain, using the W3 > validator, then can I do it automatically? Can others do it > automatically? If you want your extensions to be widely recognised and implemented, and to be considered conforming by default in validators, then the right way to do this is to develop a specification in a way that ideally receives wide review and support, particularly among implementers and web developers. This may involve working within a standards organisation, but not necessarily. If through this process, you get validator developers on board, then they will likely choose to implement support for your extension. If you don't care about support from the wider community, or if your attempts at gaining that fail, but you still want to use your extension in documents, then you have the choice to create a custom schema, (assuming there is one available for use that is sufficient for expressing the necessary conformance requirements) and provide it to the validator when validating your document. As previously mentioned, validator.nu supports the ability to use a custom schema while validating and, I believe, supports RelaxNG and Schematron. The W3C's validator only supports DTDs, with no UI for providing schemas in other formats that I'm aware of. Using one of those would require you to temporarily (just for the purposes of validation) use a custom DOCTYPE linking to it, but you would have to accept the limitations of SGML-DTD-based validation, which cannot express all the conformance requirements of HTML5. >>>> That probably helps. However, it seems that it's neither >>>> necessary (Atom validation is offered) nor sufficient (XForms >>>> validation is not offered). >>> >>> It is also a significantly newer recommendation. >> >> XForms 1.0 became a REC in 2003. The development of Atom started in 2003. > > OK. I don't know, but I guess this so because the people behind > Validator.w3.org didn't find XForms to be [relevant] on the Web? But what > does this prove? It proves the point that merely getting a specification ratified by some standards organistion is not enough for it to be recognised by authors and/or implementers. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Received on Wednesday, 20 January 2010 22:42:25 UTC