Qualified attributes

[Shawn Villaron]

Oh, yeah, I get the desire here, and understand the technical merits.  A change like this is actually one I'm inclined to support for strict.  I was more interested in seeing where everyone was regarding breaking changes to strict in general ...

-----Original Message-----
From: Jirka Kosek [mailto:jirka at kosek.cz] 
Sent: Monday, June 08, 2009 12:27 AM
To: Shawn Villaron
Cc: MURATA Makoto (FAMILY Given); SC 34 WG4
Subject: Re: Qualified attributes

Shawn Villaron wrote:

> I do worry about how each of us are reacting to the proposed namespace 
> change.  As I tried to explain in my "slippery slope" mail about a 
> week ago, I worry that some people will interpret that change as a 
> decree that since we're introducing one breaking change into strict, 
> that we can introduce as many breaking changes as we'd like.
> It's this logic that poses a substantial risk to the strict 
> conformance class.  Every breaking change we make to strict raises the 
> cost to implementers to switch over to strict.  If we really want to 
> encourage implementers to switch, we need to be very careful with the 
> changes we're making; if we're not, we could be actively discouraging 
> the outcome that many of us would like to see.

I see you concerns here, and my initial position was not change namespace for Strict at all. But as it seems that this is not the major position, I'm trying to propose changes that IMHO make sense in this new namespace setup.

I don't think that change to unqualified attributes adds any additional significant complexity in terms of refactoring existing code to deal with this..

For example code for fetching w:val attribute from w:sz element has to do something like:

getAttribute("http://schemas.openxmlformats.org/wordprocessingml/2006/main",
"val")

if we change namespace for Strict but we stick with the current attribute setup, code has to be changed to:

getAttribute("http://purl.oclc.org/ooxml/wordprocessingml/main", "val")

if my proposal about unqualified attributes is accepted then this code
become:

getAttribute("", "val")

So existing code has to be changed anyway because this change is triggered by change in Strict namespace.

I think that breaking would be to propose change to element/attribute names, for example in order to unify them between WordprocessingML and SpreadsheetML. This is tempting, but it will create too big gap between Strict and Transitional and will prevent using same tools and knowledge to deal with formats.

I hope that you will have fruitful discussion about relation between T and S in Copenhagen.

				Jirka


--
------------------------------------------------------------------
  Jirka Kosek      e-mail: jirka at kosek.cz      http://xmlguru.cz
------------------------------------------------------------------
       Professional XML consulting and training services
  DocBook customization, custom XSLT/XSL-FO document processing
------------------------------------------------------------------
 OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 member
------------------------------------------------------------------