[Bug 13467] New: Support IRI compression/shortening

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13467

           Summary: Support IRI compression/shortening
           Product: HTML WG
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P3
         Component: HTML Microdata (editor: Ian Hickson)
        AssignedTo: ian@hixie.ch
        ReportedBy: msporny@digitalbazaar.com
         QAContact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-wg-issue-tracking@w3.org,
                    public-html@w3.org


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.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Saturday, 30 July 2011 15:47:20 UTC