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

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-metadata message

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


Subject: Re: [office-metadata] Groups - Metadata_Model_Proposal_10May2007 (07-05-10-ODF-Metadaten_pld.odt) uploaded


[more]

On 10 May 2007 20:07:59 -0000, patrick@durusau.net <patrick@durusau.net> wrote:
> Greetings!
>
> The latest version with all the changes shown.
>
> Note that the question of odf:belongsTo is still under active discussion
> and its appearance in this version does not indicate a firm position of the
> editors.
>
> Hope everyone is having a great day!
>
> Patrick
>
> PS: Look for a new version tomorrow.
>
>  -- Patrick Durusau*
>
> The document named Metadata_Model_Proposal_10May2007
> (07-05-10-ODF-Metadaten_pld.odt) has been submitted by Patrick Durusau* to
> the OpenDocument - Metadata document repository.
>
> Document Description:
>
>
> View Document Details:
> http://www.oasis-open.org/apps/org/workgroup/office-metadata/document.php?document_id=23962
>
> Download Document:
> http://www.oasis-open.org/apps/org/workgroup/office-metadata/download.php/23962/07-05-10-ODF-Metadaten_pld.odt
>

The 10 May 2007 proposed changes in regard to XML Unique IDs (see page
11) are redundant and unnecessary:

"The attribute xml:id **may** occur on the following OpenDocument elements:"

The traditional XML standard definition of the word "may" is found in
RFC 2119, <http://www.ietf.org/rfc/rfc2119.txt>.

"5. MAY  This word, or the adjective "OPTIONAL", mean that an item is
   truly optional.  One vendor may choose to include the item because a
   particular marketplace requires it or because the vendor feels that
   it enhances the product while another vendor may omit the same item.
   An implementation which does not include a particular option MUST be
   prepared to interoperate with another implementation which does
   include the option, though perhaps with reduced functionality. In the
   same vein an implementation which does include a particular option
   MUST be prepared to interoperate with another implementation which
   does not include the option (except, of course, for the feature the
   option provides.)

However, the ODF specification does not clearly adopt the definitions
in RFC 2119 except to the extent that it might be argued that the
incorporation by reference of the XML 1.0 standard also imports its
incorporation of RFC 2119. Moreover, ODF section 1.5 expressly
conflicts with the "MUST" clauses of the definition of "may" in RFC
2119:

"There are no rules regarding the elements and attributes that
actually have to be supported by conforming applications, except that
applications should not use foreign elements and attributes for
features defined in the OpenDocument schema."

That language expressly instructs developers that they are free to
ignore the "MUST" clauses in RFC 2119's definition of "may," so I
believe it plain that RFC 2119 has no applicability to this issue
unless the specification's conformance section is amended to remove
such conflicts (there are others).

As the conformance section currently stands, the proposed XML Unique
ID changes only add bulk to the specification and should be removed.
Alternatively, those changes should be discussed only in conjunction
with corresponding conformance and validation issues, specifically in
regard to whether conformant applications will be required to preserve
XML Unique ID metadata inserted by other applications. Put more
bluntly, the issue is whether OOo's level of support for RDF is to
become the de facto standard for RDF support in ODF. Absent a
conformance requirement of preserving relevant metadata, that will
happen.

We presently have a conformance section so lax that an empty Zip file
is conformant ODF. The proposed XML Unique ID changes are redundant
and can not rationally be discussed without considering the
corresponding conformance and validation issues. The conformance
section's only requirement is that foreign elements and attributes
must be placed in a unique namespace. Everything else is
discretionary.

Should Sun elect not to preserve XML Unique ID metadata in
OpenOffice.org, the effect of the proposal is to make Sun's level of
RDF support a de facto standard. Interoperability with other ODF
applications that offer more complete RDF support will be
non-interoperable with OpenOffice.org. But we are preparing a de jure
standard, not a de facto standard. The MUST clauses in RFC 2119 point
the way to the correct and lawful resolution of this issue. Otherwise,
ODF will remain non-conformant with the XML 1.0 standard and with the
Agreement on Technical Barriers to Trade.

The fundamental issue raised by the XML Unique IDs proposal is whether
conformant applications will be required to preserve RDF metadata
inserted by other applications, including XML Unique IDs.

Put more succinctly, as with the lists amendment the issue is interoperability.

Best regards,

Marbux


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