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] The Rule of Least Power


Jirka Kosek <jirka@kosek.cz> wrote on 02/12/2009 07:23:55 AM:
> 
> robert_weir@us.ibm.com wrote:
> 
> > at least not obviously yes.  The nature of standardization is making 
> > choices, and it is not only respectable for an XML-based standard to 
> > define a schema that disallows generalized XML extensions, it is the 
more 
> > typical practice, in OASIS and in the W3C.  I'm not saying that there 
are 
> > not open content model standards out there, but that they are in the 
> > distinct minority.
> 
> I think that important is trend not status quo. And newer formats are
> usually using open content model. One reason is that this can be
> considered good practice and second is that open content models were
> hard to express in W3C XML Schema, but as more and more standards use
> RELAX NG for normative schema this easier to express.
> 
> For example, if I will use ODF as source for translation why should I be
> disallowed to use ITS markup
> (http://www.w3.org/TR/2007/REC-its-20070403/)? AFAIK there is no direct
> provision for this in ODF so I have to use custom attributes and
> elements. But anyone else can view/print/edit this document by simply
> ignoring ITS elements/attributes. Of course during editing those data
> will be probably discarded by application which doesn't have support for
> ODF+ITS -- but it is my responsibility to use toolchain which doesn't
> break things.
> 

I don't disagree with you here.  I've actually explored ITS and ODF 
together, and I think they would work well together.  You could specify 
reasonable semantics for how ITS-annotated ODF should behave.

So, given  <p its:translate="yes">Hello World</p>  you could say:

1)When a <p> is duplicated in its entirety, within the same document, the 
its:translate attribute shall be preserved.
2)When a <p> is duplicated in its entirety, across two ODF documents, the 
its:translate attribute shall be preserved.
3)When a <p>'s content is modified then the its:translate attribute shall 
be preserved.

However, I could give you equally plausible extension attributes which 
would require entirely different processing, and in fact would lead to 
horribly corrupted documents if the same processing rules were 
indiscriminately applied.  For example attributes with ID semantics need 
special processing during a copy to preserve uniqueness.   In other cases, 
an attribute might be a key, a cryptographic hash of <p>'s content, which 
could be freely duplicated, but would be rendered invalid by any chance to 
the elements content.  In other cases, the value of the attribute might be 
volatile and represent a timestamp or revision count, and on every edit or 
copy must be incremented or updated.

That's the general problem.  XML standards tend not to be written from the 
perspective of an editing application, where documents are created, shared 
and re-edited.  If you don't define the semantics of extensions under the 
basic editing operations, then applications will be forced to adopt a 
least-common-demominator approach to processing such extensions which 
unfortunately is to remove them entirely. 

Has anyone done this work already?  I'm surprised there is not a 
well-known standard for expressing such editing semantics.  I think most 
of my concerns would be answered if we had a standard vocabulary for 
indicating for extensions things like volatile="true", 
preserveOnCopy="false", etc.


-Rob


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