W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > September 2002

Some excerpts from AdobeXMP SDK Documentation

From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Wed, 25 Sep 2002 16:14:02 +0300
Message-ID: <00f601c26495$6b037a90$d74416ac@NOE.Nokia.com>
To: "w3c-rdfcore-wg" <w3c-rdfcore-wg@w3.org>


For consideration...

From MetadataToolkit.pdf:

The method UtilityXAP::CompareTimestamps takes as its arguments two property
"paths" (triples) and compares the timestamps represented in their literal
objects. This operates directly on the objects, not on any internalized,
pre-parsed data structures. I.e the literal objects are presumed to denote
timestamps that can be compared as timestamps, not strings.

There are also numerous methods for retrieving and storing values which
insulate the developer from any concerns about the lexical representation
used in the RDF -- i.e. applications using XMP concern themselves with
the *values* expressed in the RDF, not the lexical forms of their expression
(though there are, of course, lower level methods for manipulating the
actual lexical forms themselves, if needed). E.g. 

MetaXAP::getTimestamp
MetaXAP::setTimestamp 
UtilityXAP::GetBoolean 
UtilityXAP::GetDateTime 
UtilityXAP::GetInteger 
UtilityXAP::GetReal 
UtilityXAP::SetBoolean 
UtilityXAP::SetDateTime 
UtilityXAP::SetInteger 
UtilityXAP::SetReal 

--

From MetadataFramework.pdf:

4.2.1 XMP Core Schema

Property            Type       Description 

xap:CreateDate      Date       Description Document creation time.
xap:MetadataDate    Date       Last metadata modification time. 
xap:ModifyDate      Date       Last resource modify time. 

The XMP Date type is internally represented by a complex structure,
and applications working with Date typed property values need not
care about the lexical representation in the RDF, only the values.

4.2.2 XMP Media Management Schema

xapMM:SaveID        Integer    Incremented on each write to LastURL.

        [how does one increment a string?]

4.2.3 XMP Support Schema

xapS:Size           Integer    File size in bytes.

B.1 XMP Media-Type Schemas

xapG:NumberOfColors Integer    Number of colors in color space (256,
                               65536, etc.)
xapG:NumberOfInks   Integer    Number of process and spot colors needed to 
                               print entire document including any contained 
                               documents
xapDyn:NTracks      Integer    Number of tracks or channels Internal
xapDynV:BitRate     Integer    Bits per second Relational
xapDynV:NaturalRate Real       Fields/Frames per second Relational
xapDynA:Rate        Real       Samples per second Relational
xapDynA:SampleSize  Integer    Number of bits per sample Internal
xapDynA:Volume      Real       0.0 = silence, 1.0 = maximum volume
xapTPg:NPages       Integer    Number of pages in the document
                               (including any in contained documents)

--

From xmp_sample.xml:

<xmp:CreateDate>2001-08-13T10:42:24Z</xmp:CreateDate> 
<xmp:MetadataDate>2001-08-13T10:42:24Z</xmp:MetadataDate> 
<xmp:ModifyDate>2001-08-13T11:02:13Z</xmp:ModifyDate> 

From xmpBJ_sample.xml:

<stJob:id>1000</stJob:id> [an integer? nope, it's a string]

From xmpMM_sample.xml:

<stRef:versionID>1</stRef:versionID> [another integer? nope]
<stVer:version>1.4</stVer:version>   [a real? nope]
<xmpMM:SaveID>25</xmpMM:SaveID> 
<xmpMM:VersionID>12</xmpMM:VersionID> 

From xmpS_sample.xml:

<xmpS:Size>10000</xmpS:Size>  [ahh, here's an integer]

[You'd never know which of the above denote strings or values
unless you had knowledge of the global property-defined
datatyping semantics implicit in the XMP information models]

--

I think it's pretty evident that Adobe is expecting users of
XMP to be thinking in terms of values, not lexical representations.

Patrick

[Patrick Stickler, Nokia/Finland, (+358 40) 801 9690, patrick.stickler@nokia.com]
Received on Wednesday, 25 September 2002 09:18:47 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 3 September 2003 09:51:03 EDT