[DDI-users] A "home" for the DDI

[ddi-users@icpsr.umich.edu]

Quoting "Mark R. Diggory" <mdiggory@latte.harvard.edu>:

> I wish I could locate a private CVS service that was managed by someone 
> else. I currently maintain my own secure cvs service on my workstation 
> for several of my own projects, but I don't feel such a location could 
> be considered "stable". A good discussion might be "where to setup a 
> private CVS server?". I think the HMDC group might have an interest in 
> providing a private CVS here at HMDC unless this is something that ICPSR 
> would like to provide locally.

I'll ask around.

> I like this idea too.
> 
> In open source software development, much of this process would be 
> managed in a bugzilla or issue tracking system. It would appear there 
> are different timelines in the project for dealing with "bugs" vs 
> dealing with "feature requests". Obvious bugs require fixing almost 
> immediately in our case without much council involvement. The recent 
> codeBook "version" attribute problems that arose in the dtd and schemas 
> can attest to this necessity.

Yes, thanks, I forgot to mention that bug fixes should be dealt with using a 
different, faster process. 

...
> >> 2.) Embedding the DDI into other xml content and embedding other content
> >> into the DDI (such as OAI). This would not be able to maintain backward
> >> compatibility because DTD just doesn't support any thing near this
> >> capability.
> > 
> > 
> > This is something that requires major structural changes which would 
> > again necessitate the abandonment of backwards compatibility. Despite 
> > the X in XML, the DDI currently is not designed for extensibility. I'm 
> > not familiar with OAI schema, so I wouldn't know if they're designed for 
> > it. But if this were a council goal, then I'd suggest that XSD change 
> > and OAI embedding change be implemented simultaneously because these 
> > changes cannot be implemented without breaking backward compatibility.
> > 
> Again, this embedding is just a characteristic capability of XSD, its 
> just the capability of an XSD "Container" element, that you can place 
> any other content into that container element ( in OAI's approach, they 
> require it to carry a schema that can be validated against). From our 
> experience, there is no major modification to the contents XSD (the DDI 
> in this case) that needs occur to make it "embeddable" in OAI.
> 
> I think the issue of actually introducing this same container-like 
> functionality into the DDI, for example, with the DDI containing MARCXML 
> markup or Dublin Core XML markup, that would totally break any 
> compatibility. It would be impossible to maintain a comparable DTD if 
> such features were introduced. I'm sure there are other feature that I'm 
> not strongly familiar with that would have such requirements as well.

Let's think about this in a little more detail. If you use DDI as a wrapper, 
then you're right, you don't need to make structural changes; you can just use 
namespaces. But let me say that I don't think that the DDI should be used to 
wrap one big MARCXML or Dublin Core document. To put it another way, I don't 
think that the DDI should be used as some kind of envelope protocol the way 
that SOAP is or that TCP/IP is. My feeling is that an envelope type of 
protocol should be lightweight and singleminded. The DDI is just too big and 
clumsy to be the wrapper of a large object. Also, this kind of usage of the 
DDI does not offer any advantages to simply keeping the DDI and MARCXML or 
Dublic Core in separate documents but zipped together for easy transport. The 
value of the embedding has to come from some interaction between DDI and the 
other XML that's embedded in it.

The reason that DDI should not be used as a container/wrapper for MARCXML or 
DCXML is that they all have overlapping concerns. On the other hand, it's OK 
if DDI contains XML-FO or XHTML, because the concerns of DDI doesn't overlap 
the display concerns of XML-FO or XHTML (I'm ignoring the well-intentioned but 
misguided inclusion of formatting TEI tags). This separation of concerns is 
really the same principle underlying the 7 layers of the transport protocol -- 
each layer has its own concern so they can be independent.

So, in my opinion, if the DDI is to contain MARCXML or Dublic Core, then the 
external XML has to be broken up and stored in individual elements of the DDI. 
This would require structural changes because the concepts in MARCXML or 
Dublin Core aren't organized in the same way ( we're finding this out as the 
DDI is trying to harmonize itself with ISO1179. Many attributes match up but 
they're organized differently ). XSD offers the capability of namespaces, but 
in my opinion, mixing namespaces doesn't do any good unless the elements in 
the individual namespaces play nicely with each other.

On the other hand, the OAI seems to be a good candidate for a protocol used to 
wrap DDI, MARCXML, Dublin Core, etc., but I don't know if it's designed that 
way.