Qualified attributes

[Innovimax SARL]

Again, I support this proposal

Regards,

Mohamed

2009/6/8 Jirka Kosek <jirka at kosek.cz>

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


-- 
Innovimax SARL
Consulting, Training & XML Development
9, impasse des Orteaux
75020 Paris
Tel : +33 9 52 475787
Fax : +33 1 4356 1746
http://www.innovimax.fr
RCS Paris 488.018.631
SARL au capital de 10.000 €
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20090609/abd7dc42/attachment.htm>