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

Sun May 14 09:17:58 CEST 2017

Caroline,

Sorry for my belated reply.  I revised my document according to your
comments.

The revised doc is available at

https://1drv.ms/w/s!An5Z79wj5AZBgetAeukVNMdev5h9bA

2017-02-23 21:46 GMT+09:00 caroline arms <caroline.arms at gmail.com>:

> Murata-san,
>
> Thank you for generating a complete draft of this clause.  It is much
> easier to evaluate when you can see it all together.  This set of
> comments is from a straightforward read through your latest draft.  In
> general, this seems considerably more readable than the previous
> version I looked at.  Before the face-to-face, I plan to compare the
> draft directly to the 2012 version.
>
>     Hoping this helps.   Caroline
>
> =====
> Table 1.1
>   Need to standardize on whether the Description entries end with
> period or not.  If it would be permitted under ISO rules,

Done.  Each entry now ends with a period.

> I would like
> the group to consider whether putting links to the DC elements into
> the table makes sense.  An example is http://purl.org/dc/terms/subject

Not done yet.  Added an editorial note for this change.

>
>
> 1.2   2nd para is missing closing period.
>

Done.

>
> 1.3.1 Last para.  Missing comma after version.   I would replace
> "Here" by "In this example,".
>

Done.

>
> 1.3.3 Second para.  Says it's a note, but doesn't have [].  I'm not
> sure why it should be a note.  Why not just add the sentence about the
> namespace to the end of the first paragraph.
>

I think that it should be a note since it is not this spec that
specifies this namespace normatively.  Added [ and ].

>
> 1.3.3. Third para.  For consistency, use "This standard" in place of
> "This document."

Under the revised directives, "this document" is a correct and
convenient term.

> "Neither" doesn't work with more than one item.
>
> I suggest:
>   In this standard, these elements shall not have child elements and
> shall not have xsi:type or xml:lang attributes.
>

Done.

>
> 1.3.3.  Example numbering -- with one example referring immediately to
> another is confusing.  This happens in several places.  One way to
> address might be to invert the sentence, as in:
> Four elements from Dublin Core Metadata Element Set, Version 1.1 are
> in Example 10-1.
>

We never number examples in other parts of ISO/IEC 29500.  I have
removed all example numbers from this document.  We have to
do the same thing to entire Part 2.

>
> 1.3.4   2nd para. Here the note does have enclosing [].  Again, I
> wonder whether the sentence could not be combined with the previous
> paragraph.
>
>
Again,  I think that this should be a note.

> 1.3.4   3rd para.  Again, I would use "standard" rather than
> "document".  To match my suggestion for 1.3.3.
>

Again, "document" is correct.  But I rewrote this sentence.

> I suggest:
>   In this standard, these elements shall not have child elements and
> shall not have xml:lang attributes.
>
> 1.3.4.  Example numbering -- with one example referring immediately to
> another is confusing.
>

No numbering any more.

>
> 1.3.5.  I would use "Standard" or "Specification" rather than
> "Document" in the heading.
>

"Document" is a correct term.  It does not have to be written
when a TS becomes and IS, for example.

>
> 1.3.5   4th para.  typo in "xsd;string"  here and repeatedly in
> following subclauses
>

Done.

>
> 1.3.5.3  2nd para.  "xm:lang" should be "xml:lang"  -- this typo is
> also present more than once.
>

Done, thanks.

> To me, the second sentence is awkward, although I realize that it is
> lifted straight from Table 1 in the 2012 version.  If the only aspect
> of a keyword that can be "flagged" is its language, I think that
> should be made clear.
>

I tried to rewrite this sentence.  Comments welcome.

>
> 1.3.5.4 1st para.  I would use "keyword for the" rather than "keyword of
> the"
>

Done.

>
> 1.3.5.6  3rd para.  "xsd;dateTime" should be "xsd:dateTime"
> I would like to see an example with time as well as date.
>

Done.

>
> 1.4
> I would like to see a reference to the extensibility TR and have the
> TR in a bibliography.
>

Not done yet.  I added an editor's note.

>
> =====
>
> I have one comment that does not relate to your changes.
>
>  The value given for dc:subject in the examples is
>   <dc:subject>Spec defines the schema for OPC Core Properties and
> their location within the package</dc:subject>
> This is not consistent with the intent of the element's usage in
> Dublin Core.  See
> http://dublincore.org/documents/dcmi-terms/#terms-subject
>
> In Dublin Core -- dc:subject is, to quote, is typically "represented
> using keywords, key phrases, or classification codes. Recommended best
> practice is to use a controlled vocabulary."  In Dublin Core, although
> not in OPC, all elements are repeatable.  The usual practice for
> dc:subject is to have repeated elements, each with a term from a
> controlled vocabulary.  The content of dc:subject in the OPC examples
> is more consistent with the definition of dc:description.
>
> I recommend changing the examples to use
>   <dc:description>Spec defines the schema for OPC Core Properties and
> their location within the package</dc:description>
>

Done.  If somebody does not like this change, please respond.

Regards,
Makoto

>
> =====
>
> On Wed, Feb 1, 2017 at 3:29 AM, MURATA Makoto <eb2m-mrt at asahi-net.or.jp>
> wrote:
> > Caroline,
> >
> > 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.
> >
> > https://1drv.ms/w/s!An5Z79wj5AZBgetAeukVNMdev5h9bA
> >
> > Regards,
> > Makoto
> >
> >
> >
> > 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
> >
> > Makoto
>

-- 

Praying for the victims of the Japan Tohoku earthquake

Makoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20170514/abf02cc0/attachment-0001.html>