Open AndySky21 opened 9 years ago
In HTML there are also 'type' attributes on 'input' and 'menu' elements, where they are not used with MIME types and embedded content.
https://html.spec.whatwg.org/multipage/forms.html#states-of-the-type-attribute https://html.spec.whatwg.org/multipage/forms.html#attr-menu-type
Yes, I know. Mine was a reflection about the datatype concept, but if you replicate a list of possible type
enumerated values, it can also suit this case.
I rewrote the example to make it simpler. Please check.
I think an enumerated 'type' attribute should be fine, and I'm avoiding the MIME-type syntax.
Apart from enumerated type (which is necessary) on <model>
and <field>
, don't worry about MIMEtype syntax on <fixture>
. I strongly prefer it to simple type="json"
syntax. On a strictly theoretical POV, you are using a language which is not proper HTML and needs specific parsing (as it would be in case of a .json external file). In this case you should use type="application/json"
, as well as proper type values on script and stylesheets (both inline and external) is text/javascript
and text/css
respectively (JS being text/
and not application/
is a sad historical mistake which will never be solved IMHO).
Of course it will be possible to omit type on fixtures, and in that case it could be assumed application/json
as implied/default value.
You still have
type
attribute on<model>
and<property>
elements. As stated before,type
is not global, but it is usually specified on embedded content, so it sounds misplaced in this case. The idea would be to replace it withdatatype
, but as you probably know, that attribute is used in RDFa Core (with a similar meaning, actually). Ideally there wouldn't be room for RDFa/HMML*, as model does not define content so it would make no sense to semantically mark it up. Consider using it, also comparing existing cases with model as you figure it.*As you know from the mailing list, I strongly suggest you to discard the HTML6 concept. Focus on your model and propose an external markup specification as it was done for SVG, MathML etc. In this case I'd call it HMML, HyperModel Markup Language.