RE: [dita] Negative values - scoped values

[Michael Priestley <mpriestl@ca.ibm.com>]

I guess what I'm trying to do is:

- provide some support for wildcard
filtering without opening the door to complete string matching capabilities,
specifically by allowing a value to have multiple components
- provide some semantic justification
for those components which can then be mapped to a more complete, taxonomy-friendly,
centrally-managed solution to be defined later

So while I agree the long-term goal
is centrally managed taxonomies, I think we need to let implementations
scale gradually to that goal, ie not force a group to adopt centrally managed
taxonomies when simple wildcard matches will do the trick.

In 1.2, I'm hoping we can create a relationship
between the values in these attributes and key values in maps, so that
we can leverage map hierarchies to establish and manage the relationships
between the values centrally. But that's overkill for 1.1, as well as for
many groups that have simple metadata requirements, and we do have a requirement
in the meantime for wildcard-based filtering. 

The approach I proposed was meant to
be a compromise between the two extremes: unrestricted wildcard filtering
with no semantics, and fully restricted taxonomy-based management of metadata
with rich semantics. 

I hope this clarifies the intent of
the current proposal,

Michael Priestley
IBM DITA Architect and Classification Schema PDT Lead
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25

"Paul Prescod" <paul.prescod@blastradius.com>

04/18/2006 02:14 PM

To	Michael Priestley/Toronto/IBM@IBMCA, "Esrig, Bruce \(Bruce\)" <esrig@lucent.com>
cc	"Chris Wong" <cwong@idiominc.com>, <dita@lists.oasis-open.org>
Subject	RE: [dita] Negative values - scoped values

Ultimately, my question is not
whether some values have relationships to other values but whether those
relationships are best expressed in each document or in a configuration
file (schema?) where they can be centrally managed.

---

From: Michael Priestley [mailto:mpriestl@ca.ibm.com]
Sent: Tuesday, April 18, 2006 8:07 AM
To: Esrig, Bruce (Bruce)
Cc: Chris Wong; dita@lists.oasis-open.org; Paul Prescod
Subject: RE: [dita] Negative values - scoped values


The scoped values also allow different kinds of classification: effectively,
if one set of values has an "is-a" or "part-of" relationship
to another set, it makes sense to express them as a single value, both
semantically and for processing reasons. 

For example, products have editions - but if you set product="A B
C" and edition="2" then it's unclear which product the edition
applies to; whereas if we set product="A B/2 C" it becomes much
clearer. 

Michael Priestley
IBM DITA Architect and Classification Schema PDT Lead
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25

"Esrig, Bruce (Bruce)" <esrig@lucent.com>

04/18/2006 10:57 AM

To	Michael Priestley/Toronto/IBM@IBMCA, Chris Wong <cwong@idiominc.com>
cc	dita@lists.oasis-open.org, Paul Prescod <paul.prescod@blastradius.com>
Subject	RE: [dita] Negative values - scoped values

As a taxonomy enthusiast, I like scoped values. From a logical point of
view, scoped values are not necessary if you are only manipulating one
value, because you can specify all its qualities in different attributes.
  
If the situation can only be described using two values both of which are
scoped, then you need scoped values to avoid unintended combinations.
  
Without scoped values, you can describe items using multiple attributes
as in this example: 
  
establishment-type="bar hotel" establishment-name="NewYorker
Plaza" 
  
would have four intepretations 
  
bar/NewYorker 
bar/Plaza 
hotel/NewYorker 
hotel/Plaza 
  
If you meant to say 
  
establishment="bar/NewYorker hotel/Plaza"
  
then you need scoped values. 
  
Bruce 
-----Original Message-----
From: Michael Priestley [mailto:mpriestl@ca.ibm.com]
Sent: Tuesday, April 18, 2006 10:49 AM
To: Chris Wong
Cc: dita@lists.oasis-open.org; Paul Prescod
Subject: RE: [dita] Negative values


There was a comment submitted to the TC asking for wildcard filtering -
I was reluctant to allow full wildcard filtering because of its reliance
on informal semantics (eg win* won't match desktopwin, and *win wouldn't
match windows but would match notwin). 

I thought allowing scoped values - with separate components that have a
bit more formal identity - would increase flexibility without sacrificing
formality (ie we're still dealing with whole values, even if they're part
of a compound). 

There was some discussion of this on the dita-users list prior to the comment
submission, but I have to admit I don't think we discussed it on the TC
list. 

Michael Priestley
IBM DITA Architect and Classification Schema PDT Lead
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25

"Chris Wong" <cwong@idiominc.com>

04/18/2006 10:42 AM

To	Michael Priestley/Toronto/IBM@IBMCA, "Paul Prescod" <paul.prescod@blastradius.com>
cc	<dita@lists.oasis-open.org>
Subject	RE: [dita] Negative values

I think he means "scoped values". From your spec:
 
    audience="programmer/database programmer/Java programmer/Web"
 
I'm surprised to see this in the spec too, since I was not aware that there
is significant demand for this. Maybe I missed the discussion.
 
Chris

---

From: Michael Priestley [mailto:mpriestl@ca.ibm.com]
Sent: Tuesday, April 18, 2006 10:24 AM
To: Paul Prescod
Cc: dita@lists.oasis-open.org
Subject: Re: [dita] Negative values


What scope attribute? 

Michael Priestley
IBM DITA Architect and Classification Schema PDT Lead
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25

"Paul Prescod" <paul.prescod@blastradius.com>

04/18/2006 10:03 AM

To	<dita@lists.oasis-open.org>
cc
Subject	[dita] Negative values

This document describes negative values:

http://www.oasis-open.org/committees/download.php/17329/IssueNumber20.ht
ml

It isn't explicit about the semantics of them. For example, it implies
that negative and positive values can be combined in a single attribute
(otherwise why say that the NOT operator only applies to a single
value). But I would have thought that a negation of value A implies
value B by definition. Therefore explicitly stating value B is
redundant.

audience="NOT paul"

Means everybody but paul. Therefore saying "everybody but paul plus
janice" is redundant. In programming language terms:

If Audience!=paul OR audience=janice

Although I am a fan of the goals of this feature, I am not convinced
that we can work out the details in the time we have. Plus I think that
it is a bit of scope creep beyond what the TC agreed to. The same goes
for the scope attribute.

Paul Prescod