dita — archive
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
— [Date Index]
| [Thread Index]
| [Month Index]
| [List Home]
RE: [dita] Negative values - scoped values
MHonArc v2.5.0b2 -->dita message
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] Negative values - scoped values
- From: Michael Priestley <[email protected]>
- To: "Paul Prescod" <[email protected]>
- Date: Tue, 18 Apr 2006 15:09:36 -0400
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
[email protected]
http://dita.xml.org/blog/25
| "Paul Prescod"
<[email protected]>
04/18/2006 02:14 PM |
|
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:[email protected]]
Sent: Tuesday, April 18, 2006 8:07 AM
To: Esrig, Bruce (Bruce)
Cc: Chris Wong; [email protected]; 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
[email protected]
http://dita.xml.org/blog/25
| "Esrig, Bruce (Bruce)"
<[email protected]>
04/18/2006 10:57 AM |
|
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
— [Date Index]
| [Thread Index]
| [Month Index]
| [List Home]