Re: Schemas and validation

> approaches to validation of HTML/XHTML

Thanks for the recap information. Now I remember the list of 
validation topics I was to study. Seems like I have been living in a 
stable and predictable environment and have not been exposed to the 
rigors of real world validation of something with such abundant 
composability that it is removed from the realm of schemata, or maybe 
I have been stuck at some 'acceptable' level of validation ignoring 
some vital details. However most people work on more complicated 
publishing mashups than me.

> Although I think it is wrong to not provide formal schema as a part 
> of HTML5 spec, ...

I think if I am a specifier, then maybe at least I would like to hear 
and see some proof of the word Recommendation. For example, I would 
like to think that out of all this html5 stuff, at least here is 
something that can be fairly represented by standards-track .xsd.
Warning: this .xsd may not represent all possible allowances and 
restrictions made by a UA working on text/html, but it does describe 
in reasonable detail recommended structures and content types for 
elements and value types for attributes supported by this standard.
Warning: This model is somewhat restricted from the written standard 
for acceptable stuff but satisfies modern coding practices that should 
work in all browsers served as text/htm(5). This does not signify a 
profle or version of html, just typical content models that can be 
used for static validation of complete documents.
Exceptions: none known, because if it can't be modelled by .xsd then 
it won't make it into this "html5 Recommended Schema' so the feature 
or exception or fixups or deprecsoleted features won't be widely used 
for new content.
.
At this point, I need a list of what would be lost if the element 
structures and contents and attribute values that could not be 
represented with intended functionality using  .xsd, were not included 
in this schema.
Yes, @srcdoc and anything that reasonably has to be tested visually 
and functionally or externally anyway may not need to be in this 
schema. Additional constraints and admonitions like these: the 
interactive element video with the attribute controls must not appear 
as a descendant of the a element, or as a descendant of the button 
element, might not be convenient to be in the schema, but those strike 
me as being something I would want to test by running the thing using 
some provided conformance test to see if it mattered to my favorite 
browser anyway. Regex and other simple processing/simultation might be 
included, but this is a schema for the masses that don't care about 
that legacy stuff or trick constructions and just want to get down 
with basic transportable html5. Almost at the level of the html5 
vocabulary reference document with meaningful content models 
allowed -- not an attempt to show the total  power of html5 as 
delivered by top W3C HTML5 WWW browsers, but an appropriate point for 
common agreement on currrent recommended best HTML practice and base 
for continued development of HTML.

>> Then that should not be an acceptable structure (because it cannot 
>> be validated by XML schema...)

> Sorry, but this is completely wrong reasoning.

Well, now I think <video> with its conditional structure can be 
validated but .. another thread...
OK, but I started off with the idea that every element has a content 
model that can be represented by .xsd. if it wouldn't work in .xsd 
then keep thinking until it does or else fix .xsd if possible. 
Evidentally there are common html5 models or important constraints and 
admonisions that cannot be represented in .xsd. I would say throw them 
out of contention for acknowledgement in this schema.

So, I still think the WG should produce a standards-track .xsd for 
HTML that can show describable content models and let it go at that. I 
think even in limited form, and while not fullfilling all requirements 
in the standard, it would be very useful.

Thanks to All and Best Regards,
Joe

Received on Wednesday, 3 March 2010 16:10:11 UTC