WG4's handling of DR-09-0248 - General: Removing the need for qualifiers on attributes in Strict

[Innovimax SARL]

Well

Even if I can share some suspicion with Rex, I don't agree on the fact
that it is too big a change to be done

1) It is not our fault if IS29500 is more than 5500 pages long. If it
wasn't so big, it wouldn't be so troublesome to update it. So now I
don't thing it is a good idea to NOT MAKE change because it need a lot
of text update. Going that way, why are we

2) My understanding is that after AMD-1, IS 29500 will be reissued to
incorporate all the AMD and COR so far ; if it is not the case, I'm
sorry, but it is already not usable with the current volume of AMD and
COR that are planned. So even if we add an order of magnitude of
changes, it is already too much to be tractable

3) Handling attributes with namespace is not an ascetically change, it
is *much more* to be inlined with what are the current use of
attribute in XML with namespaces  and it makes processing of such
attributes more natural to users

4) It already inconsistent in the spec since there is places where
prefixed attributes are use and other places where non prefixed
attribute are used

5) Since it is harder to deal with prefixed attributes, it will make
existing implementation simpler

Regards,

Mohamed

2009/7/3 Jirka Kosek <jirka at kosek.cz>:
> Rex Jaeschke wrote:
>
>> 1. In 25 years of working on 9 standards, my experience has been that most
>> non-trivial changes/additions made at the last minute turn out to range in
>> quality from problematic to disastrous.
>
> This change is in principle very trivial, it "just" affect too many code
> listings shown in examples.
>
>> 2. A week ago in Copenhagen, we pushed back hard on this specific proposal.
>>>From the minutes:
>>
>> "There was broad support for adopting the proposed solution. After some
>> discussion, it was agreed that the solution involved changes to narrative,
>> examples and schemas covering at least 800 pages spread through Parts 1 and
>> 4. And qualified versions of some examples from Part 1 will need to be added
>> to Part 4. The Project Editor estimated that the effort needed to implement
>> this solution was on the order of that for all the other DR resolutions
>> combined. Given the time available before the planned start of the ballots,
>> members saw no way that such a big editing task and WG4 review can be
>> accomplished. As such, resolution of this DR will be considered after the
>> closure of the COR1 and AMD1 sets."
>>
>> I remain unconvinced that the task has gotten any simpler since then.
>
> If you assume that AMD1 should literally contain all changes made in
> code listings in *informative* examples, then I agree that amount of
> editorial work is so large that it is unreasonable to do it in AMD1. But
> I'm not convinced that amendment should literally contain changes in
> those code listing, especially because of the sheer volume of changes.
>
>> 6. Finally, we have some non-trivial implementations out there living just
>> fine with this "wart". Does it really need "fixing"? It's mighty tempting
>> during standards making to "just do it right" and clean up certain
>> unpleasant artifacts. However, to a very large extent, we are consolidating
>> prior art here, we're not crafting a new spec from scratch.
>
> This is true for Transitional. But as namespace for Strict was changed
> and compatibility with existing applications was already broken it is
> chance to do little bit more cleanup.
>
> If we want to have cleaner Strict and use unqualified attributes then we
> should make this change now or never. Postponing the change to a next
> set of CORs/AMDs would mean that Strict is not stable but radically
> changing beastie -- something what people are not expecting from IS and
> our WG.
>
> It would be interesting to know what others think about this issue and
> sufficiency of editing instructions I have proposed.
>
>                        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 €