Talk:ESciDoc Content Model Object

Moved to descussion

---

• schema of main metadata record
• schema of main metadata record

for sake of simplicity we could always name the main metadata record "eSciDoc"--Natasa 11:46, 10 November 2008 (UTC)

Custom name should be possible. Default value may be "escidoc". Frank 17:23, 10 November 2008 (UTC)

---

Maybe flags, if specific methods create new version.

do not understand what this means--Natasa 13:30, 10 November 2008 (UTC)

The idea was to have something like "submitting creates new version or not" (maybe submitting is a weak example). Frank 14:22, 24 July 2009 (UTC)

---

Maybe flags, if specific methods create new version.

do not understand what this means--Natasa 13:30, 10 November 2008 (UTC)

Probably we should also add a flag if a content-stream is allowed or not for resources of this CModel--Natasa 13:30, 10 November 2008 (UTC)

In my opinion if content-streams are allowed or/and restricted by occurrence or name etc. should be stated like as for components (not key/value section!?). Frank 17:23, 10 November 2008 (UTC)

Frank, my understanding was that it is only 1 (one) content stream possible. If it is not, then certainly it is the same pattern definition like for components. --Natasa 09:24, 11 November 2008 (UTC)

I see! Yes, several content-streams are possible. Frank 10:27, 11 November 2008 (UTC)

---

Lists

• model specific properties

defines which properties (key-value pairs) are allowed to put in the content-model-specific section of an Item or Container. An allowed property is defined with name, datatype, and occurence. (May be obsolete because content-model-specific in Item and Container is seen as metadata and may be removed.)

I would still not keep with this assumption. We have in content-model-specific properties in R4 put "local tags" i.e. those which are valid for publication items only, and are not indeed real Tag-relations.--Natasa 11:53, 10 November 2008 (UTC)

At ESciDoc_Developer_Workshop_2009-03-17 discussed; content-model-specific is needed by MPDL for "local tags" and will remain in item and container properties. I would educe local tags are not handled by the infrastructure from storing them in c-m-s element!? Maybe we just should provide a XML Schema for c-m-s element instead of a key-value list? Frank 08:45, 17 March 2009 (UTC)

Because content-model-specific is deprecated, now, there will be no specialized part to define the content. But it should be possible to define/validate content by rule- or modeling language. Frank 14:33, 24 July 2009 (UTC)

Removed model specific properties from proposal. Frank 15:08, 27 July 2009 (UTC)

---

• additional metadata records

Name, schema, and occurrence of additional metadata records. Maybe a flag to just allow additional unspecified metadata records.

Name and schema would be better, as the content model - beside descriptive information that holds only flag should also offer the possibility to map between differents chemas. --Natasa 11:53, 10 November 2008 (UTC)

What is meant by occurence of additional metadata records? not clear with this information, probably we should not keep this information. --Natasa 11:53, 10 November 2008 (UTC)

Yes, name and occurrence may be in conflict, because name of a metadata record must be unique inside one object. Frank 10:37, 11 November 2008 (UTC)

Obviously we need name-schema pairs (a md-record with name name must be conform to schema). Additionaly it would be nice to state if a md-record is optional or mandatory (a md-record with name name must exist and must be conform to schema). Additionaly, for the entire object, it should be possible to state if it is allowed to add md-records not defined in the content model (a flag to allow additional unspecified md-records; default should be not allowed) Frank 08:52, 17 March 2009 (UTC)

Removed occurrence of metadata from proposal. Frank 15:12, 27 July 2009 (UTC)

---

Enhanced Scientific Documentation

Coordinated Universal Time

Max Planck Digital Library

Extensible Markup Language