[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: OOXML pack scheme, ODF fragment identifier and the W3C package URIdiscussion (earlier - Re: [office] Announcement of work on ODF 1.2 metadatafeature adoptions)
Hello Dennis,
Thanks for the feed-back. The package scheme is only one possible
solution to create an URI to resolve sub-content from a package (like an
OpenDocument package).
The W3C created yesterday a new mailing list regarding the topic of
package URI, where I just posted different scenarios and solutions for
package URIs [1].
The pack URL is no solution for us, because it is still only a
provisional schema at IANA [2].
As there is no package scheme standardized, I would suggest to await the
results of the W3C list.
Due to large amount of proposals, I hereby withdraw my fragment
identifier proposal for ODF 1.2 and postpone it to the successor.
You might want to do the same for your proposal as the scheme is
provisional, Dennis.
To show you the advantage of the fragment identifier approach over a
package URI, please let me give you the following preview of the
fragment proposal:
I will propose the current syntax [3] for all ODF media types and
furthermore add a mime dependent syntax to provide higher usability.
For instance for an ODF spreadsheet document a user might create an URI
with the following fragment identifier:
The sub-content of the spreadsheet
http://www.oasis-open.org/test.ods
might be resolved in the following order by an ODF aware application:
1) Abbreviation to an xml:id of the /content.xml
http://www.oasis-open.org/test.ods#someID
2) Cell Range of spreadsheet
http://www.oasis-open.org/test.ods#mysheet.B5:C7
3) Cell of spreadsheet
http://www.oasis-open.org/test.ods#mysheet.B5
4) Named Range
http://www.oasis-open.org/test.ods#someName
5) DataBase Range
http://www.oasis-open.org/test.ods#someName
6) Number as Line number of spreadsheet
http://www.oasis-open.org/test.ods#mysheet.42
7) Sheetname
http://www.oasis-open.org/test.ods#some%20sheet
8) Name of graphic (e.g. chart)
http://www.oasis-open.org/test.ods#myGraph
Imagine the power for the user to reference a subset of any ODS document
in the web, even without having write permissions to add an ID!
But that is meant only as a preview to show the advantage over a package
scheme. The fragment identifier proposal should be discussed after
finishing ODF 1.2.
Regards,
Svante
[1] http://lists.w3.org/Archives/Public/public-pkg-uri-scheme/
[2] http://www.iana.org/assignments/uri-schemes/prov/pack (cp. 2. Status)
[3]
http://wiki.oasis-open.org/office/Change_Proposal_for_ODF_1.2_using_URL_fragment_identifiers_for_ODF_media_types
Dennis E. Hamilton wrote:
> 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).
>>
>>
> [ ... ]
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
--
Sun Microsystems GmbH Svante Schubert
Nagelsweg 55 Software Engineer
20097 Hamburg StarOffice / OpenOffice.org Development
Germany Phone: +49(0)40 236 46 500
http://www.sun.com Svante.Schubert@sun.com
Sitz der Gesellschaft:
Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]