13467 2011-07-30 15:47:13 +0000 Support IRI compression/shortening 2011-08-09 00:41:54 +0000 1 1 1 Unclassified HTML WG LC1 HTML Microdata (editor: Ian Hickson) unspecified PC Linux RESOLVED WONTFIX P3 normal --- 1 msporny ian ayg eoconnor ian mike philipj public-html-admin public-html-wg-issue-tracking public-html-bugzilla oldest_to_newest 51816 0 msporny 2011-07-30 15:47:13 +0000 This feedback is filed as a personal comment and is not intended to be any sort of official feedback from any standards working group. Currently, Microdata requires the use of absolute IRIs in @itemtype and absolute IRIs or terms in @itemprop. This means that the use of any non-hardcoded vocabularies in the Microdata specification requires those that want clean URLs out of their markup must use absolute IRIs. This is bad for at least two reasons: 1. Absolute IRIs are difficult to type repeatedly and are thus very error-prone. 2. Performing vocabulary mixing can be overly verbose. For example, if one wanted to mix schema.org vocabulary terms with OGP vocabulary terms in Microdata, you would be required to use absolute IRIs. This could bloat the markup considerably for large data sets: https://plus.google.com/u/0/105458233028934590147/posts/Q2Wnvy1ysBD I suggested that Microdata create some sort of IRI compression or shortening mechanism. RDFa has CURIEs, but Microdata need not go that far - you could just have a repository of compact IRI prefixes that are hardcoded or known to the Microdata specification and that could be used by Microdata authors. Something like: schema:Person or schema.Person or schema.name or ogp.url would expand to the correct values without requiring a prefix-rebinding mechanism. 51843 1 philipj 2011-07-30 22:32:41 +0000 Brining back Java-style identifiers (org.schema.Person) would also cut down a bit on the identifier size. I'm not sure many would understand that org.schema.Person and http://schema.org/Person are not interchangeable, though. 51865 2 ayg 2011-07-31 14:41:06 +0000 Yeah, I don't know why we require URLs here. Why do we need any kind of namespacing at all? Why not allow arbitrary strings and have an open registry, as for rel and <meta name> and such? It would cut down on verbosity a lot. 51969 3 ian 2011-08-02 07:25:25 +0000 EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: It turns out that in practice regular authors have no problem with the verbosity here. It's only us geeks who get offended by it. (I was really surprised by this when I saw it in the lab. I had originally done the reverse-DNS thing to address this problem, as I think it does it quite neatly, but it turned out to be quite unnecessary.) In practice this will be a non-issue. The only place you will regularly see URLs is the itemtype="", but those can be made short by vocabulary authors if that is desired, and they will be relatively rare anyway (at least compared to the number of other URLs in Web documents). Properties will almost always be short names, either when using common vocabularies, or when using untyped vocabularies for personal adhoc use. The use of URL property names is expected to be a rarity and is only there to enable extensions. 52958 4 mike 2011-08-04 05:05:37 +0000 mass-move component to LC1 54424 5 msporny 2011-08-09 00:19:27 +0000 For the record, I think not supporting some sort of vocabulary mixing and IRI compression is a mistake. I am not happy with the Editor's response because it doesn't address my concerns. That said, I'm not going to pursue this bug due to time constraints.