Re: [office] custom schemas, metadata

[Bruce D'Arcus <bruce.darcus@OpenDocument.us>]

On Jan 27, 2006, at 7:40 AM, Bruce D'Arcus wrote:

> Just came across this last night from Microsoft's Brian Jones on 
> custom schemas in Office:
>
> <http://blogs.msdn.com/brian_jones/archive/2006/01/25/517739.aspx>
>
> What's interesting about his example is that it is actually all about 
> (mostly custom) metadata.

Just a quick followup:

See Brian's subsequent comments in the above blog entry.

In particular:

> The value of the additional structure often relates to the value of 
> the document itself. This isn't a scenario where you as an end user 
> would want to do it so that you could search through your files 
> easier. It's a scenario where your company would want to set up 
> templates so they could manage hundreds of thousands of documents. The 
> approach people have taken up until now is to use meta-data; but that 
> isn't tied directly to the content, so you have to force the user to 
> take an additional step of filling out the meta-data. Pushing data 
> back into the document for document generation scenarios is also a lot 
> easier with the custom XML support.

He's totally right about the bigger picture, and also wrong; in 
particular that one has to choose one or the other (content vs. 
metadata).

... and:

> ... It's important to note though that our goals with the custom 
> schema support was not to turn Word into an XML editor like XMetal. 
> Instead we wanted to bring structure to existing Word scenarios. We've 
> seen a large number of customer solutions where they were using things 
> like styles and bookmarks to imply semantics to certain portions of 
> their documents, and we wanted to make that easier and more robust. 
> You can work with any schema you want in Word, but you'll find that 
> the more complex the schema is, the harder it will be to work with (as 
> you probably expected).
>
> -Brian

He's pretty much laying out the market/use case opportunities here, and 
echoing in part our discussion.

One way to understand the possibilities, then, is this:  we have the 
opportunity here to provide a superior alternative to MS custom schema 
support! It would be a different, in some ways more simple and elegant, 
solution to the same problem.

Bruce