Thanks for the reply. If I understand what you're saying right, then under the current design all schema.org values have to be in Solr stored fields, such as title_vern. 

The use case for the architecture I'm trying to describe, using the doc extension sutff, is providing for more flexibliity, so schema.org values do not have to be in Solr stored fields, but can come from other places.  For a SolrDocument with an associated MARC record, the schema.org values could be looked up from inside the MARC record.  For a SolrDocument with an associated oia-dc XML, the schema.org values could be looked up from the XML. Etc.   There could still be a default 'base' implementation that looked up the values from Solr stored fields. 

In my own app, I simply don't keep title or author etc in Solr stored fields. I have very few Solr stored fields.  I instead extract values like that from the MARC record at _display time_, rather than writing code to extract the values from the MARC record at index-time and store them in stored fields.  This is because the code to get that stuff out of MARC is pretty complicated; I wanted to do it in ruby (rather than SolrMarc, when I was using that), and I also wanted to be able to _change_ this logic without doing a re-index.

But I realize now that the schema.org stuff is embedded only in the default view that does take all the values from Solr stored field. If I'm not using that view (as I'm not), then I guess I wouldn't get it anyway. 

So, I dunno, maybe what I'm describing doesn't apply anyway, it would only apply to a different more flexible architecture that gave you a set of tools for embedding schema.org stuff in your own view. Not entirley sure if that would be useful after all, and I guess it would be a different thing than whats going on here. 

Thanks for sticking with me here. Sorry if I wasted your time. Sorry if you still have no idea what i'm talking about. :)