[whatwg] MetaExtensions for HTML5 vs. custom tagging

[Michael[tm] Smith]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Christine Smith <christin at 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 at name registration mechanism and conformance
checkers are all agnostic toward whatever taxonomy you want to use for
meta at 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 at 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 at name value you register will pass validation. Whatever
schema you might have that defines some relationship among your meta at name
values, it's irrelevant to validation. You can't, say, register a set of
IBM.* meta at 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 at 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-----