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: [OASIS Issue Tracker] Issue Comment Edited: (OFFICE-3418) 19.278form:id seems to be inconsistent



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

Dennis Hamilton edited comment on OFFICE-3418 at 9/27/10 12:12 AM:
-------------------------------------------------------------------

I agree with Andreas on this one.

This observation can only be a note, so it should be what can happen were an ODF 1.2 consumer to accept an ODF 1.0/1.1 document as if it were ODF 1.2.  

An alternative is to simply say that when an xml:id is missing but the other *:id is present, its value shall be treated as of type ID rather than as a simple NCName and also deprecate the other *:id form.  I think I already proposed as much based on what the schema currently is.

Michael Stahl provided some changes to the schema that may not allow for this statement.  We need to review that.  I will see if I might stumble over the place where this came up.

The place where this has been discussed already is OFFICE-3317.  There I propose a change to the schema that works such that if there is only the text:id, it is an ID, and if there is a xml:id, it is the ID and the optional text:ID is then an NCName (so there is no conflict with them having identical values).  This allows ODF 1.0/1.1 document to have these case processed as of ODF 1.2 by an ODF processor, if it choose to, and the downlevel use in an ODF 1.0/1.1 processor should also work provided that the text:id element is there (with or without the xml:id).

This seems to be what is in our power to support, if we choose to do so.  This avoids a silly statement about processing something as if it is an ID when the schema says no such thing and there are all sorts of problems if the schema doesn't (since the value must then be unique in the XML document as an ID).

      was (Author: orcmid):
    I agree with Andreas on this one.

This observation can only be a note, so it should be what can happen were an ODF 1.2 consumer to accept an ODF 1.0/1.1 document as if it were ODF 1.2.  

An alternative is to simply say that when an xml:id is missing but the other *:id is present, its value shall be treated as of type ID rather than as a simple NCName and also deprecate the other *:id form.  I think I already proposed as much based on what the schema currently is.

Michael Stahl provided some changes to the schema that may not allow for this statement.  We need to review that.  I will see if I might stumble over the place where this came up.
  
> 19.278 form:id seems to be inconsistent
> ---------------------------------------
>
>                 Key: OFFICE-3418
>                 URL: http://tools.oasis-open.org/issues/browse/OFFICE-3418
>             Project: OASIS Open Document Format for Office Applications (OpenDocument) TC
>          Issue Type: Bug
>          Components: Forms
>    Affects Versions: ODF 1.2 CD 05
>            Reporter: Andreas Guelzow 
>            Assignee: Patrick Durusau
>            Priority: Minor
>             Fix For: ODF 1.2 CD 06
>
>
> In 19.278 form:id we have
> "If there is no xml:id attribute value, then a form:id attribute should be processed as it were an xml:id attribute."
> and later
> "An element shall not have an form:id attribute if it has no xml:id attribute value."
> So in view of the second sentence, the first one doesn't make sense: if there is no xml:id attribute then there cannot be a form:id attribute that could be processed as it were an xml:id attribute.

-- 
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

        


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