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] Potential Issue: When Does Applicability Apply to Key Space Determination?


I agree with Eliot that we need to say "must" to ensure all
implementations are indeed interchangeable. 


--
Gershon

-----Original Message-----
From: ekimber [mailto:ekimber@reallysi.com] 
Sent: Monday, November 02, 2009 11:34 PM
To: Ogden, Jeff; dita
Cc: Robert D Anderson
Subject: Re: [dita] Potential Issue: When Does Applicability Apply to
Key Space Determination?

On 11/2/09 5:18 PM, "Ogden, Jeff" <jogden@ptc.com> wrote:

> Eliot asked:
> 
>> So I guess we really have two questions:
>> 
> 
>> 1. Does anyone disagree with the assertion that "filter first"
>> is/should be the working principle of the DITA 1.2 standard?
> 
> I agree with this, but feel that because this is coming so late in the

> DITA 1.2 cycle and because the DITA 1.0, 1.1, and up until now DITA 
> 1.2 specs have been silent about order of processing issues, that if 
> we are going to include this in DITA 1.2 that it should be a SHOULD 
> rather than a MUST.
> 
>> 2. If everyone agrees that "filter first" is the principle to apply 
>> to processing generally, does anyone disagree with the conclusion 
>> that
> key
> 
>> spaces must therefore reflect the effect of filtering?
> 
> I agree with this too and make the same comment about SHOULD rather 
> than MUST in DITA 1.2.

I don't see how this can be a should: there needs to be exactly one rule
for key space construction, otherwise there cannot be interoperability
of processors for key-based addressing.

Either filtering is *always* applied or it's *never* applied. I don't
think a middle ground is helpful.

Since the Toolkit currently does filtering before keyspace construction,
it effectively requires *all* implementations to do so as well.

I would be much happier, as both a tool vendor and a tool user, to have
that situation be formally defined by the standard rather than not. In
particular, I don't want to be on either side of the situation where the
CMS or authoring tool *doesn't* apply filtering to key spaces and the
Toolkit does. Nobody in that situation would have any authority for
supporting their position but they would be able to also claim that it
wasn't *disallowed* by the standard. That would be an impasse I'd very
much like to avoid.

The key mechanism is the most important thing in DITA 1.2 and the one
thing that is essential for DITA to be truly useful (because without it
you can't have both reuse and xrefs). We have to get it right.

Cheers,

E. 


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


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 



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