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] Proposed change to Monday's agenda (IRI's versus URI's)

Hi all,

first of all: I will cancel today's agenda in favour of adressing the two 
issues below.

Regarding CSS3: We are referencing the CSS3 Text Module, but only as 
documentation. Which means, OpenDocument specifies some attributes, and 
references the CSS3 Text Module to provide a description of the semantics of 
the attributes.

The state of this specification is a "candidate recommendation". If this is 
an issue, we may of course include our own description of the attributes in 
the specification. However, since we are specifying our own attributes, we 
should be independent of the state of CSS3 text module. If it changes or is 
withdrawn, our own specification should remain valid.

What is in fact an error is that the URL of the CSS3 Text Module is missing 
in the bibliography.

Regarding DOM level 3 events: We are referencing the DOM 3 specification in 
section 12.4.1:

"For events that are specified in the DOM event model, it is recommended to 
use the event names described in 1.4.2 of [DOMEvents]. The corresponding 
namespace is "http://www.w3.org/2001/xml-events";.

We also have a list of events in section 11.6.1, but without a reference to 
DOMEvents. This list contains also short description of the events.

The DOM level 3 specification is a working draft. Since the list of events 
contains a description, I'm not sure if this is an issue.

Regarding IRI: OpenDocument uses the XSD "anyURI" datatype for URIs, in most 
situations as value of an xlink:href attribute.

While the definition of this datatype in the W3C Schema Datatype 
specification mentions only URIs, the document


as well as RFC2987 (http://www.ietf.org/rfc/rfc3987.txt) in section 1.2 state 

"IRIs and IRI references can be in attributes and elements of type "anyURI""

So, I'm not sure whether the issue that Japanese Standards Body sees is the 
usage of the "anyURI" type for attributes that may contain URI or IRIs, or 
whether the issue is that the OpenDocument specification does not mention 
that IRIs are allowed where "anyURI" is used as datatype.

In the first case, we may of course provide our own type definition for 
"anyURI", which explicity permits IRIs. In the later case, we may clarify 
that OpenDocument does not restrict the "anyURI" type to URI (or URLs) even 
if use these terms, or we may explicitly mention IRIs.

In any case, it is not the intention of the OpenDocument specification to 
specify restrictions regarding the protocols that can be used with URIs, nor 
is it the intention of the OpenDocument specification to require that 
conforming application support certain protocols. This applies to IRIs (that 
are themselves a protocol), but also to other protocols.

Best regards


robert_weir@us.ibm.com wrote On 01/20/06 18:02,:
> I've been handed some unofficial feedback from the Japanese standards 
> body, indirectly forwarded to me via IBM's Japanese subsidiary.  It 
> appears that ODF's use of URI's rather than the new unicode IRI's 
> (http://www.w3.org/International/O-URL-and-ident.html) has been received 
> poorly, and may result in an unfavorable ISO vote from Japan.
> They are also questioning ODF's use of CSS3 and DOM level 3 events, 
> since neither were formally adopted by the W3C.  The suggestion was to 
> define necessary portions of these specs in the ODF spec, rather than by 
> reference.  (IMHO, this seems like more of an editorial comment than a 
> technical one.)
> I'm asking that we agree to take on this issue on Monday's call as a 
> priority issue.  The next meeting of their standards group will be 
> before the end of the month, so there is some urgency for the TC to 
> state if and how they will address this issue before then, which could 
> turn around their vote.  
> I'm no expert in this area, but it seems a possible fix would be to 
> allow an IRI every place in the spec where a URI is currently specified. 
>  Would this cause any other issues in the specification?  Any 
> implementation issues?
> The tricky part might be where we reference an external specification 
> which has not been updated to allow IRI's. (SVG?  SMIL?).  If there is 
> any data which is essentially shared between legacy URI-based standards 
> and newer IRI-aware standards, then we'll need to be careful how they 
> interface.
> Do we agree that this IRI issue is a legitimate concern with ODF 
> documents in Japan (and potentially China, Korea, etc.)?
> Can I get some +1's for adding this to the agenda for Monday?
> -Rob

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