Carl

first: this is not a draft, IIM Schema for XMP is an approved standard!

see more below ..

On 18 Jul 2008 at 15:16, Carl Rambert wrote:

> A) Three IIM fields 2:10 Urgency, 2:15 Category, and 2:20
> Supplemental Category are represented in, and synchronized with,
> photoshop:Urgency, photoshop:Category, and
> photoshop:SupplementalCategories by Adobe today, even though they
> were not adopted in the approved IPTC Core schema for XMP. They are
> listed as deprecated. But they are "still synchronized with the XMP
> property", ... "hence available for future use -- but outside the
> IPTC Core."
>
> If the IPTC use definitions are consistent with these photoshop
> fields, then might it be prudent to specify the photoshop namespace
> fields instead of defining three new Iptc4xmpIIM namespace fields?
>
> At least the implementation note for each should make reference to
> this past assignment in the photoshop namespace.

We were aware but: a) there three fields are not in the IPTC Core and the goal
of this "IIM
Schema" is to map all IIM datasets which are not in the IPTC Core and b) as
anybody is free
to define a XMP property and to map IIM Dataset we decided not trying to reflect
XMP
properties outside the IPTC Core.

Ok, but we should add a note to make this clear in the document.

>
>
> B) Content Location - Since alignment of Code and Name is required in
> the IIM implementation, I suggest that this dictates an XMP bag array
> structure to maintain the alignment.
>
> Iptc4xmpIIM:ContentLocation bag ContentLocationDetails (structure)
>
> ContentLocationDetails (structure)
> Code Text
> Name Text

The goal of the "IIM Schema for XMP" is not to add any functionality over IIM. I
agree to your
design thoughts but as no sub-structure for Code/Name exists in IIM no such
structure was
adopted for the XMP schema

>
>
> C) Reference - 2:45, 47, and 50 are repeatable in "sequential
> triplets" in IIM. I suggest that this dictates an XMP seq array
> structure to maintain the alignment of the triplets.
>
> Iptc4xmpIIM:Reference seq ReferenceDetails (structure)
>
> ReferenceDetails (structure)
> Service Text
> Date Date
> Number Text
>

See my note above, the same applie here.

>
> D) XMP property id choices - The cryptic XMP property id "IIM2-003"
> for "2:003 Object Type Reference" , for example, runs counter to the
> practice used in IPTC Core where the XMP property id "SubjectCode"
> was used for "2:012 Subject Reference". I suggest that the property
> id be formulated from the property name, not its IIM encoding
> assignment.

As said in the introduction to the specification document the goal was to
provide a simple
expression of IIM fields in XMP. For that reason we adopted a simple naming
convention,
the more as some IIM dataset name are pretty lenghty.

>
>
> E) 1:90 Coded Character Set -- IIM has a rich set of choices for
> this property. Unfortunately, the (typical) absence of this metadata
> property means "default system character set" which varies on
> different platforms. XMP is only implemented in UTF-8. The platform
> interoperability benefit that XMP offers is an important motivation
> for defining this schema. It warrants mention in the introduction.

Hm, I don't get the idea of this comment: 1:90 is not included into the XMP
schema as it
completely pointless: the character encoding of an XMP packet has to follow the
XMP rules
which are - as you say - "use UTF-8".
>
> F) Appendix: Mapping of all IIM properties -- It would be useful if
> the twenty IPTC IIM properties that are missing from this table were
> added with "Not mapped, not relevant"

Ok, we could a this in an updated document revision.

Michael

==================================================
Sent by:
Michael Steidl
Managing Director of IPTC <mdirector@...>
International Press Telecommunications Council
Working to improve the efficiency of News exchange.
Visit our Web Site at http://www.iptc.org