dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [dita] weak/strong constraint proposal
- From: Michael Priestley <mpriestl@ca.ibm.com>
- To: "Ogden, Jeff" <jogden@ptc.com>
- Date: Tue, 13 Oct 2009 09:54:08 -0400
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]