Re: [dita] weak/strong constraint proposal

[ekimber <ekimber@reallysi.com>]

I agree with Michael's analysis. I also agree that making "weak" the default
is sensible.

Cheers,

E.

On 10/13/09 8:54 AM, "Michael Priestley" <mpriestl@ca.ibm.com> wrote:

> I agree that the copy/paste thing is a tangent.
> 
> With respect to Su-Laine's assessment of applicability for 1.2, I
> disagree:
> 
> - I do think we're enforcing constraints more than we should for some of
> the authoring-focused use cases
> - And the general task/constrained task is one of those use cases
> - So if we proceed with strong constraints only, that will mean inhibiting
> a reuse scenario that several people have called out as likely
> - We will also be limiting the usefulness of constraints to implementers
> of new doctypes as well,
> - And even if we provide a relaxed form in a future release, we won't be
> able to make weak the default (we'd need to keep strong as the default,
> for backwards compatibility with existing implementations)
> 
> So I am inclined to fix it now, ie in 1.2. The weak constraints proposal
> below requires no changes to the doctypes already implemented, since we
> want weak constraints on task anyway. So the main change is to distinguish
> in the spec between strong constraints (all the currently-described
> behavior) and weak constraints (ignored by conref, should not be relied
> upon by processing).
> 
> Michael Priestley, Senior Technical Staff Member (STSM)
> Lead IBM DITA Architect
> mpriestl@ca.ibm.com
> http://dita.xml.org/blog/25
> 
> 
> 
> From:
> "Ogden, Jeff" <jogden@ptc.com>
> To:
> <dita@lists.oasis-open.org>
> Date:
> 10/11/2009 02:08 PM
> Subject:
> RE: [dita] weak/strong constraint proposal
> 
> 
> 
> I don?t understand why ?Constraining a document will affect copy/paste as
> well as conref?.  It might, but not in the same way or to the same extent.
>  
> It is true that copy/paste needs to be DTD valid by the time it is done,
> but so do other forms of editing changes.  What is validated is the actual
> markup to be inserted.  And implementations are free to make copy/paste as
> smart or as dumb as they wish and can, but are not required to, transform
> the material being pasted as necessary in an attempt to make it valid.
>  
> Conref validation is different. It isn?t DTD validation and uses
> information from the domains and possibly the class attribute to validate
> potential rather than actual markup.
>  
> So copy and paste from a general task to a strict task could work
> depending on what markup is being moved, while conrefing the same markup
> from a general task into a strict task won?t work (at least not for
> ?strong? conref validation).  But the same could be said for copy and
> paste and conref between different topic document types that use different
> domains and which do not use constraints.
>  
>     -Jeff
>  
> From: Su-Laine Yeo [mailto:su-laine.yeo@justsystems.com]
> Sent: Friday, October 09, 2009 8:42 PM
> To: Michael Priestley; dita@lists.oasis-open.org
> Subject: RE: [dita] weak/strong constraint proposal
>  
> Thanks Michael. I see the value in the proposal and I don?t have a
> specific objection to it, however to start the discussion I?ll recap a
> couple of things I?ve mentioned in off-list discussions and in a previous
> TC meeting:
>  
> 1) Constraining a document will affect copy/paste as well as conref. If
> you constrain out <lq> elements, for example, you won?t be able to paste
> anything that contains a <lq> element and have it be valid. Depending on
> your authoring tool, it could mean not being able to paste that content at
> all unless you remove the <lq> element first.
>  
> If an organization?s goal is to simplify the user experience for authors
> (by presenting a smaller element list), but they don?t want to strictly
> disallow any structures, using constraints will be a problematic way to
> achieve their goal regardless of whether we adopt this proposal.
>  
> 2) There are features on the DITA 1.3 list that I think are
> higher-priority than this proposal.
>  
> I?m open to being persuaded otherwise, but for now I think that we should
> focus on what is already in 1.2.
> Happy Thanksgiving to the Canadians, by the way! I?ll be out of the office
> on Monday Oct 12.
>  
> Best regards,
> Su-Laine
>  
> Su-Laine Yeo
> Interaction Design Specialist
> JustSystems Canada, Inc.
> Office: 778-327-6356
> syeo@justsystems.com
> www.justsystems.com
>  
>  
>  
>  
> From: Michael Priestley [mailto:mpriestl@ca.ibm.com]
> Sent: Friday, October 09, 2009 2:07 PM
> To: dita@lists.oasis-open.org
> Subject: [dita] weak/strong constraint proposal
>  
> 
> The following proposal is relative to the existing constraint design
> documented here: 
> http://www.oasis-open.org/committees/download.php/25090/IssueConstraints12008.
> html 
> 
> 
> I'm starting with the assumption that we would want the default or normal
> behavior to be weak constraints - so I'm proposing a notation to declare
> when a constraint should be respected/required for interoperability, and
> letting the default be to assume that the constraint is not required.
> 
> ------------------
> 
> Proposed notation: optionally precede the normal constraint declaration
> with an "s" for strong.
> 
> Example: 
> s(topic hi-d basicHighlight-c)
> 
> This notation is parallel to the notation for attribute domains, where a
> leading "a" is used to identify the value as having special meaning.
> 
> Normally-declared constraints are to be ignored by conref processing, in
> order to ease sharing between groups that have implemented constraints
> primarily to enforce authoring guidelines, rather than for strict
> processing requirements.
> 
> If there is a processor or other strong dependency on a constraint being
> present, then the constraint can be declared in the document type with the
> prefix "s". The constraint should then be handled in exactly the way
> currently described in the existing design.
> 
> --------------------
> 
> Let me know if this is enough - it's a fairly simple proposal, relative to
> the existing one :-) But if it would be useful for me to go in and edit
> the original, I can.
> 
> Michael Priestley, Senior Technical Staff Member (STSM)
> Lead IBM DITA Architect
> mpriestl@ca.ibm.com
> http://dita.xml.org/blog/25
> 

----
Eliot Kimber | Senior Solutions Architect | Really Strategies, Inc.
email:  ekimber@reallysi.com <mailto:ekimber@reallysi.com>
office: 610.631.6770 | cell: 512.554.9368
2570 Boulevard of the Generals | Suite 213 | Audubon, PA 19403
www.reallysi.com <http://www.reallysi.com>  | http://blog.reallysi.com
<http://blog.reallysi.com> | www.rsuitecms.com <http://www.rsuitecms.com>