OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [dita] weak/strong constraint proposal

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

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.  
From: Su-Laine Yeo [mailto:su-laine.yeo@justsystems.com]
Friday, October 09, 2009 8:42 PM
Michael Priestley; dita@lists.oasis-open.org
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 Yeo
Interaction Design Specialist

JustSystems Canada, Inc.
Office: 778-327-6356

From: Michael Priestley [mailto:mpriestl@ca.ibm.com]
Friday, October 09, 2009 2:07 PM
[dita] weak/strong constraint proposal


The following proposal is relative to the existing constraint design documented here:


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.


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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]