OASIS Open Document Format for Office Applications (OpenDocument) TC

Greetings! This question is broader than the fo, svg, smil "compatible" namespaces but it is a place to start the discussion. As you know, elements and attributes in the "compatible" namespaces share some but not all of the values, behaviors and semantics of those elements and attributes in their native namespaces. As part of ODF 1.3/ODF-Next, I would like to see the attributes and elements of other namespaces used *as defined* in those namespaces. In part it is a question of separation of concerns and expertise. I assume that while we have members of the ODF Committee who are conversant with fo, svg, smil, that the committees that maintain those standards have deeper wells of expertise to draw upon. It would make maintenance of ODF proper easier if we re-use standards developed by experts in those areas, not to mention enabling implementers to use a modular approach that selects libraries/engines for those particular standards. That re-use of other standards and software, however, presumes that our usage is consistent with that of the standards we are invoking. This is not simply a matter of convenience for the standards committee but how this will affect current and future implementers of ODF. So I anticipate discussion/debate on the various options before us. Just to pose something to respond to, let me phrase the proposal as follows: For ODF 1.3/ODF-Next (tbd) the elements and attributes in the fo, svg, smil "compatible" names spaces should be reformed to be consistent with their native namespaces. I am sure there are all sorts of variants but please take that as a straw proposal for discussion purposes. Hope everyone is at the start of a great week! Patrick -- Patrick Durusau patrick@durusau.net Chair, V1 - US TAG to JTC 1/SC 34 Convener, JTC 1/SC 34/WG 3 (Topic Maps) Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300 Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps) Another Word For It (blog): http://tm.durusau.net Homepage: http://www.durusau.net Twitter: patrickDurusau

Patrick Durusau <patrick@durusau.net> wrote on 07/18/2011 09:30:57 AM: > > Greetings! > > This question is broader than the fo, svg, smil "compatible" namespaces > but it is a place to start the discussion. > > As you know, elements and attributes in the "compatible" namespaces > share some but not all of the values, behaviors and semantics of those > elements and attributes in their native namespaces. > > As part of ODF 1.3/ODF-Next, I would like to see the attributes and > elements of other namespaces used *as defined* in those namespaces. > > In part it is a question of separation of concerns and expertise. I > assume that while we have members of the ODF Committee who are > conversant with fo, svg, smil, that the committees that maintain those > standards have deeper wells of expertise to draw upon. > > It would make maintenance of ODF proper easier if we re-use standards > developed by experts in those areas, not to mention enabling > implementers to use a modular approach that selects libraries/engines > for those particular standards. > > That re-use of other standards and software, however, presumes that our > usage is consistent with that of the standards we are invoking. > > This is not simply a matter of convenience for the standards committee > but how this will affect current and future implementers of ODF. So I > anticipate discussion/debate on the various options before us. > > Just to pose something to respond to, let me phrase the proposal as follows: > > For ODF 1.3/ODF-Next (tbd) the elements and attributes in the fo, svg, > smil "compatible" names spaces should be reformed to be consistent with > their native namespaces. > For sake of discussion, do you have some examples in mind where ODF defines these attributes in a divergent way? I remember seeing that SVG "points" were defined as integers in ODF 1.1, but floats in SVG. Is that the kind of thing you are thinking of? > I am sure there are all sorts of variants but please take that as a > straw proposal for discussion purposes. > > Hope everyone is at the start of a great week! > > Patrick >

XLink appears to be profiled in a way that is contrary to that specification also. As I recall, it has to do with the XLink policy about default values and the ability to have an XLink processor that independently handles XLink attribute occurrences in an element correctly. I think there are also deviations in what the XLink attribute applies to. - Dennis
Original Message----- From: robert_weir@us.ibm.com [ mailto:robert_weir@us.ibm.com ] Sent: Tuesday, July 19, 2011 07:34 To: ODF TC List Subject: Re: [office] fo, svg, smil "compatible" namespaces Patrick Durusau <patrick@durusau.net> wrote on 07/18/2011 09:30:57 AM: > > Greetings! > > This question is broader than the fo, svg, smil "compatible" namespaces > but it is a place to start the discussion. > > As you know, elements and attributes in the "compatible" namespaces > share some but not all of the values, behaviors and semantics of those > elements and attributes in their native namespaces. > > As part of ODF 1.3/ODF-Next, I would like to see the attributes and > elements of other namespaces used *as defined* in those namespaces. > > In part it is a question of separation of concerns and expertise. I > assume that while we have members of the ODF Committee who are > conversant with fo, svg, smil, that the committees that maintain those > standards have deeper wells of expertise to draw upon. > > It would make maintenance of ODF proper easier if we re-use standards > developed by experts in those areas, not to mention enabling > implementers to use a modular approach that selects libraries/engines > for those particular standards. > > That re-use of other standards and software, however, presumes that our > usage is consistent with that of the standards we are invoking. > > This is not simply a matter of convenience for the standards committee > but how this will affect current and future implementers of ODF. So I > anticipate discussion/debate on the various options before us. > > Just to pose something to respond to, let me phrase the proposal as follows: > > For ODF 1.3/ODF-Next (tbd) the elements and attributes in the fo, svg, > smil "compatible" names spaces should be reformed to be consistent with > their native namespaces. > For sake of discussion, do you have some examples in mind where ODF defines these attributes in a divergent way? I remember seeing that SVG "points" were defined as integers in ODF 1.1, but floats in SVG. Is that the kind of thing you are thinking of? > I am sure there are all sorts of variants but please take that as a > straw proposal for discussion purposes. > > Hope everyone is at the start of a great week! > > Patrick > --------------------------------------------------------------------- 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