OPC Core Properties -- WAS: My latest draft of OPC

MURATA Makoto eb2m-mrt at asahi-net.or.jp
Wed Feb 1 09:29:11 CET 2017


I think that the existing clause of core properties is short
of providing normative definitions.  For example, the existing
table of core properties does not make clear that the creator
element can have no child elements.  Where is this requirement
specified?  It is in "11.4 Schema Restrictions for Core
Properties".  The same applies to the xml:lang attribute.  It
is allowed only for the keywords element and the value
element, but this requirement is shown in "11.4 Schema
Restrictions for Core Properties" only.  I don' think that
this is the right approach.

Here is my proposed rewrite of this entire clause.



2017-01-26 22:43 GMT+09:00 caroline arms <caroline.arms at gmail.com>:

> Murata-san,
> Thank you for clarifying that your intention was to retain the table
> at the beginning of the Core Properties clause.  That had not been
> clear to me.
> I would like to echo a comment made by Rex on yesterday's call that
> Part 2 is so different from Parts 1 and 4 that it doesn't seem
> necessary to follow the patterns established there in detail.  To me,
> what matters is whether the clause is easy to understand.
> My concern is that following the shape of your suggestion here will
> make the Core Properties clause much more awkward to read than it need
> be and than it is now.  For example, for the element "identifier" you
> would need to look at the table to understand its semantics, to
> http://purl.org/dc/elements/1.1/identifier to see what Dublin Core
> actually defines it as (which your increased emphasis on the fact that
> it is borrowed from Dublin Core seems to require), and to the schema
> in our Annex to find that it is optional (although your suggested
> re-write doesn't point there for the borrowed elements).
> This all seems unnecessarily complex for elements that are almost all
> of type xsd:string (or the equivalent SimpleLiteral from the Dublin
> Core schemas our schema incorporates) and optional, and must not have
> the xml:lang attribute.
> And for dcterms:created and dcterms:modified, we also need to look at
> 10.5 Schema restrictions for Core Properties
> This morning I have not come to a conclusion as to how I would try to
> address your concerns about missing information without making the
> clause more cumbersome, but I'd like to encourage you to include the
> whole clause in your next re-write suggestion to make it easier to
> review.
> I need to turn to other matters now.
>    Thanks.  Caroline
> [Aside: The fact that our schema refers to
> http://dublincore.org/schemas/xmls/qdc/2003/04/02/dc.xsd and
> http://dublincore.org/schemas/xmls/qdc/2003/04/02/dcterms.xsd  for
> typing is a complication we can't avoid.  I'm not sure I had looked at
> those since they were first put together and it was strange to see the
> names of good friends as the authors!]
> On Mon, Jan 23, 2017 at 10:03 AM, MURATA Makoto
> <eb2m-mrt at asahi-net.or.jp> wrote:
> > Dear colleagues,
> >
> > Attached please find my latest draft.  Carolline and Francis
> significantly
> > contributed to it.  Recent changes relate to relationships parts.
> >
> > https://1drv.ms/f/s!An5Z79wj5AZBges7CzR1SJWYniS-Yg
> >
> > Long time ago, I proposed a rewrite [1] of OPC core properties.  Since
> WG4
> > has
> > not discussed it yet, I did not incorporate it into this rewrite.
> >
> > [1] http://mailman.vse.cz/pipermail/sc34wg4/2016-August/003941.html
> >
> >
> > Regards,
> > Makoto


Praying for the victims of the Japan Tohoku earthquake

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20170201/8962d838/attachment.html>

More information about the sc34wg4 mailing list