- From: Michael[tm] Smith <mike@w3.org>
- Date: Fri, 21 Feb 2014 04:25:11 +0900
- To: Christine Smith <christin@us.ibm.com>
- Cc: whatwg@whatwg.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Christine Smith <christin@us.ibm.com>, 2014-01-16 10:21 -0500: > Over the years, my company has developed custom IBM.xxx meta tags for our > internal and external web pages that are used by various internal tools. My > question has two parts: > > 1) Is there an allowance for custom taxonomy definition The HTML specification and meta@name registration mechanism and conformance checkers are all agnostic toward whatever taxonomy you want to use for meta@name values you register. Each of the registered values is effectively seen just as a opaque string with no relationship at all to any of the other registered values. > that is not a proposal for general acceptance? The majority of the meta@name values that are currently registered are not for general acceptance -- if by general acceptance you mean values that have some shared utility in multiple tools or services on the Web. The majority of the registered values are semi-private values that have utility to only one tool or service somewhere. > For example, if we manage our own company-specific meta data schema and > linked our pages two it, would it pass validation? Each individual meta@name value you register will pass validation. Whatever schema you might have that defines some relationship among your meta@name values, it's irrelevant to validation. You can't, say, register a set of IBM.* meta@name values by referencing a schema. Instead you just have to list and register each individual value as a separate string. > If so, is there a spec that shows how to create our own schema? You don't need to provide a schema. You just to need to provide each meta@name value with a link for each to some document that defines what that one value means. Of course if you want, that document can be something that defines a schema that specifies how those values are related to one another. But it's not necessary for the values to be related to each other in any way, and not necessary to explain how they are related to each other if there is some relationship. > 2) The "Registered Extensions" table at > http://wiki.whatwg.org/wiki/MetaExtensions still show status of "proposal" > for all tags. Does that imply that they are not fully accepted as > extensions? For example, > -- I would like to know that Dublin Core is accepted, so that I can rely on > its continued support. Anything that's listed in the first table on that page is accepted for the purposes of validation. Whatever purposes there might be other than validation are basically just hypothetical. > -- However, there are also redundant examples in that table (e.g. > web_author and designer) Those are only redundant if you expect it's required for the values to actually mean something standard, or to mean what they look like they should probably mean. You could register the string "this_means_old" if you wanted to, and then define it as meaning "new", as long as you provided a link to some document that gave it that definition. > and tool-specific proposals that could be made more generic for broader > use (e.g. Web Trends wt.xxx could become analytics.xxx). As far as I know, nobody's planning to do that. I think the organizations who've registered values that only work with their tool or service are probably happy with what they have and don't show any signs of being interested in spending time on trying to get agreement about values with standard meanings that might accomplish the same thing. > Is there a timeline to update the status to "accepted" for those that will > be supported in the future? There's no such timeline I'm aware of -- and as far as I can see, nothing at all would change in practice if and when any particular value were to move to "accepted". --Mike - -- Michael[tm] Smith http://people.w3.org/mike -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCgAGBQJTBlaXAAoJEIfRdHe8OkuVauUP/1SNvmSNNP/a+TKnBfxlnAN2 n+gOAf7evb3GNRoM4QJmih8lTwC1Lvj6wknpz5pVC4QLTE8mHtHC179i9HvLTNT3 NnAYZbqH5UwhvPZpnRe0BUrJ3cec20BXJ90DMlSqRPwgc5DFZ6evjNvY3GuRCusV hw5gaJUGdOxzUDeBTvfX8c7Wm6qDnx6ZA2iUi65EsawfoF45ldKvXLPeQ4DoYi9B 2B+KMvwH8TK680+bM3xTSHU9XVByfLxc9wjabHK/g/TtHTQV0sHnWYOxJMzB7awL 43SyGpO0aBwrvuqgwfRf8njL6UfC/1G6MfkgjevGY8/889o7aTBTULoQJ258dWI8 mzCxU2rzquN8pk9DzbxlOY17bLwzXZX5bgOj/mV0vAqRiHyuuuv93K4xk55i2alU TEFyorQwGUXyDpKC31VLg8RqIkHJt1lseekUHBuAiql42+qNR6qZSXbzRc5Ho3Sf FRtn+ygjz+PCd1S4b/FsVY9tv/I7gTOiEOBGRuIxtZq1UynmVD4Su5FqWwM0O07C fsxEGHNWvIdeMbVusaBHOtxWJvoEloPpLmcDY06h6vivxhrg+L42PBbWwhBp04s/ ObKgHogoknOyl1SUw/mclvUIiLkgdYWVPziW02hUhfhdh/ry+peRqCbuvrGdUErB qFJhn8OPsLRy44Pye3nq =4ZDF -----END PGP SIGNATURE-----
Received on Thursday, 20 February 2014 19:25:40 UTC