Qualified attributes

Jirka Kosek jirka at kosek.cz
Mon Jun 8 09:26:38 CEST 2009


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 258 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20090608/30e9eec2/attachment.pgp>


More information about the sc34wg4 mailing list