OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [office] Announcement of work on ODF 1.2 metadata feature adoptions


Now that IS 29500 is available, you might want to look at applying the Part
and Pack URIs of the Open Packaging Conventions for references in and out
and around in ODF packages.  (Actually, the pack: URI scheme is worth
looking at with regard to ODF 1.2 more broadly, since it is already
available for use via the anyURI type according to Annex B of IS 29500-2).

I am thinking specifically of the IS 29500-2:2008 section 9, Package Model,
with subsections 9.1 Parts and 9.2 Part Addressing.  There is no requirement
to support OPC Relationships for ODF, and some other OPC portions can be
avoided as well (e.g., fragments).  I imagine that part URIs can be used
quite nicely in RDF, and the fit into the metadata extensions should work
quite well.  Have the W3C folk looked at this? 

 - Dennis

PS: There is also substantial work on physical packaging and mapping to Zip
that would be useful for ODF in terms of clarity and dealing with the
complexity of URLs whose paths pass through a variety of resolution regimes
(i.e., through a Zip to a file system to something else).  There is also
useful nomenclature In this regard, section 10 has valuable material,
especially with the way it is rigorous around mapping to a Zip archive in
section 10.2.  Annexes A-C are also very useful and we could avoid having to
duplicate that level of work (although there might be exceptions for ODF).
The main difference for ODF packages is the use of the special MIMETYPE item
and the absence of OPC Relationships (but having the RDF-based extensions).

PPS: Although I have wondered about this ever since I saw the early OPC and
ODF specifications, the topic fell off my radar for anything to do with ODF
1.2 until the connection with RDF usage came to mind.  Consequently, I am
going to add consideration of this to the ODF 1.2 task list [1]

PPPS: IS 29500-2:2008 is available as a free download for individual use.
See 
http://nfoworks.org/diary/2008/11/isoiec-295002008-ooxml-standard.htm

 

-----Original Message-----
From: Svante.Schubert@Sun.COM [mailto:Svante.Schubert@Sun.COM] 
http://lists.oasis-open.org/archives/office/200811/msg00168.html
Sent: Saturday, November 29, 2008 06:08
To: office@lists.oasis-open.org
Subject: Re: [office] Announcement of work on ODF 1.2 metadata feature
adoptions

Dear TC members,

I have divided the changes mentioned below into four minor proposals and 
added them to our ODF 1.2 task list [1].
The proposals will be finalized till 10th of December including all 
suggested wordings.

Regards,
Svante

[1]  http://wiki.oasis-open.org/office/OpenDocument_v1.2_tasks

Svante Schubert wrote:
http://lists.oasis-open.org/archives/office/200811/msg00006.html
[ ... ]
>
> 3)
> The SWIG where rather puzzled by the usage of generated URNs in the 
> ODF/RDF examples. The web lives from URLs, so will be the Semantic 
> Web. Aside of this, there is a design rule in the "Architecture of the 
> World Wide Web" not to create alias [6]. Everybody strongly suggested 
> to use relative URLs within the package and to reference to the 
> resources within the package with URLs.
> Unfortunately that triggers the problem of referencing from outside 
> inside the ODF package by URLs, when making these relative URLs absolute.
>
> In general there are three possibilities:
> a) Using an URL that thinks of a package similar as an directory
> b) A package schema similar to 'jar:' that has never been standardized
> c) Create own fragment identifier for our mimetypes.
>
> Currently I believe a) & b) are valid and desired options, but out of 
> the scope of our TC (not to mention the time frame), therefore I have 
> asked to discuss this general package related problem at the W3C Web 
> Technical Architecture Working group (further details at [7] and thread).
>
[ ... ]



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]