[OASIS Issue Tracker] Commented: (OFFICE-2156) [xml-names] ODF 1.2profile

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ http://tools.oasis-open.org/issues/browse/OFFICE-2156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16484#action_16484 ] 

Michael Brauer commented on OFFICE-2156:
----------------------------------------

Dennis, do you agree that #1 and #4 are already resolved?

Do you also agree that #5 could be achieved by replacing  "namespace-well-formed" with "namespace-valid"  in D1.4.1 (part 1) and PD1.6.1 (part 3)?

Regarding #2: I still believe that we should not explicitly forbid relative namaspace URIs. We are not defining such. That's important. But if someone uses them for other namespaces than those ODF defines although they are deprecated, then that happens on the risk of the author of document, as it is the case for any other deprecated feature.

Regarding #3: I still think since we are not defining a DTD, adding clauses that only have an impact if a DTD is used, is confusing and not necessary.

Regarding #5: I had a look at the errata for XML-Names that contains the rationale for the "namespace-valid" conformance target. 

http://www.w3.org/XML/xml-names-19990114-errata

It says in NE08: "It was unclear whether such errors as colons in IDs rendered a document non-conformant. This erratum makes it clear that they do not, and also provides terms paralleling XML 1.0's well-formed and valid."

I have no string objections to requesting namespace-validity, but when reading the rationale, I am not sure if it is the intention of authors of XML-Names that all applications of XML-Names switch to the namespace-validity conformance target. If that would be the case, then they could have re-defined namepsace-well-formedness. I therefore are in favor of keeping our clauses as they are.


> [xml-names] ODF 1.2 profile
> ---------------------------
>
>                 Key: OFFICE-2156
>                 URL: http://tools.oasis-open.org/issues/browse/OFFICE-2156
>             Project: OASIS Open Document Format for Office Applications (OpenDocument) TC
>          Issue Type: Bug
>          Components: Conformance, External References, OpenFormula, Packaging
>    Affects Versions: ODF 1.2
>         Environment: This issue applies to the current (2009-10-21) drafts for ODF 1.2 Part 1 and ODF 1.2 Part 3.  The issue applies to ODF 1.2 Part 2 to the extent that any normative appeal to [xml-names] is not eliminated from that part of the specification.
>            Reporter: Dennis Hamilton
>             Fix For: ODF 1.2
>
>
> For ODF 1.2, it is proposed that the [xml-names] reference be to "Namespaces in XML 1.0 (Second Edition), W3C Recommendation 16 August 2006," http://www.w3.org/TR/2006/REC-xml-names-20060816/ (see OFFICE-2148).
> In previous versions of ODF specifictions, [xml-names] refers to "Namespaces in XML, W3C Recommendation 14 January 1999," http://www.w3.org/TR/1999/REC-xml-names-19990114/
> Most differences are benign.  However, there are a few substantive differences that must be accounted for:
> 1. The 2006 W3C Recommendation SUPERSEDES the 1999 W3C Recommendation.  
> 2. Relative URIs are deprecated as namespace names.
> 3. There is clarification about where namespace declarrations must appear, and that may require a normative profile clause.
> 4. [RFC3986] is referenced instead of [RFC2396].
> 5. The Conformance clauses are different.
>     5.1 For XML documents, there are now two conformance classes:  namespace-well-formed documents and namespace-valid documents are all conformant documents.  The namespace-well-formed documents correspond exactly to the only conformant documents  of the 1999 specification.  The namespace-valid documents are namespace-well-formed documents for which it is the case that "no attributes with a declared type of ID, IDREF(S), ENTITY(IES), or NOTATION contain any colons."
>    5.1.1 For ODF 1.2 documents, a namespace-well-formed document could be defined as one in which every XML document that comprises the ODF document representation is a namespace-well-formed XML document.  For ODF 1.2 documents, a namespace-valid document could be defined as one in which every XML document that comprises the ODF document representation is a namespace-valid XML document.
>    5.1.2 We could then assert that a extended/conformant ODF 1.2 document shall be a namespace-well-formed document and that it should/shall be a namespace-valid document.
>   5.1.3 For ODF 1.2 packages, we might assert that at least those XML documents defined as essential to the package structure itself in Part 3 shall be namespace-well-formed XML documents and should/shall be namespace-valid XML documents.
>    5.2 There are now definitions for [xml-names] conforming processors.  A processor, in this context, is a subsystem that would be used by an ODF document consumer.  This does not directly express conditions on ODF consumers and producers.  Instead, we could profile ODF cases as follows,
>    5.2.1 An extended/conformant ODF producer could be defined such that it all XML documents that comprise the produced ODF document representation shall be namespace-well-formed XML documents and should/shall be namespace-valid XML documents. 
>   5.2.2 The existing definition of an extended/conformant ODF consumer should work without modification so long as it is expressed in terms of extended/conformant ODF documents.
>   5.3 [xml-names] now specifies the behavior of a processor when it detects that the namespace-validity or namespace-well-formedness conditions are not met.  It seems preferable to state, for ODF packages and ODF documents, that the behavior is implementation-dependent, since it is the ODF consumer that decides how to act on what a compliant [xml-names] processor reports to it, including how to make a meaningful report from the ODF implementation to the office software user.
> Related Issues:
> OFFICE-2148 on XML Namespaces
> OFFICE-2155 on Reconciling ODF 1.2 External References

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira