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: Groups - Action Item Modified: #0015 Post summary of categories for l...



OASIS Darwin Information Typing Architecture (DITA) TC member,

Don Day has modified this action item.

Number: #0015
Description: Post summary of categories for l...
Owner: Mr. Paul Prescod
Status: Open
Due: 23 Aug 2005

Comments:
Seraphim Larsen  2005-08-15 22:02 GMT
This Action Item came out of the following discussion from the 8/9/05 TC meeting:

I. Proposal for general attribute addition.
http://lists.oasis-open.org/archives/dita/200508/msg00009.html

- Paul Prescod -- Originally interpreted item #20 (above) as
the ability to add any kind of attribute to specialized
elements in DITA. Was surprised to learn that it is only
metadata/profiling attribute. Any attribute that does not
fit model is not generalizable.

DITA should support arbitrary attributes. Important for
migration legacy to DITA -- may need to capture legacy
metadata. Should be done at 1.1 or 2.0.

Allow any attributes to be extensible. Problems relate to
generalization and respecialization. Must be lossless. Must
find a way to tunnel arbitrary attributes to other
attributes. Syntactic issues, difficult to implement in
XSLT, and impossible to deal with in CSS.

Should this be dealt with sooner or later?

- Don: Chris Wong raises issue -- whether scope creep
jepardizes schedule/feasibility for adoption. Requests that
discussion continue on list.

- Don: What is the usability of the proposed feature? Writers
are loath to work with attributes unless they are really,
rally motivated to do so. Is this motivated by good design
principals rather then whether writers will really use this.

- Chris Kravogel: When we convert legacy DTDs to dita, there
are two approaches:
Convert attributes to attributes, or
Convert attributes to data elements, perhaps in an alternate
location that might be more convenient.

- Paul: Where can data element occur?

- Chris Wong: How necessary is it to maintain attributes as
attributes?

- Don: Data element is intended to hold real data.
 element is there for theings that don't
fit nicely. Perhaps editor requires writer to disambiguate
content.

Paul Prescod -- wheter attributes are really necessary. What element
is appropriate for info that really is metadata?

Don: Proposal to convert attribute value to text content.
More general question -- 1. general migration of attributes.
2. supporting architected attributes in a general way. Want
them to be created and used by authors. Extension mechanisms
are intended to support ongoing design in your DTD.

Have we really considered usability aspect of general
attribute declaration mechanism. If we create it, will
writers use it? Is it not just a good idea, but something
that will add value.

Paul: Usability is handled by the tools. DITA already has
hundreds of attributes.

Dana Spradley -- Using data elements would be much less
usable than attributes. E.g., we can hide attributes. Can't
hide elements. People thinking of migrating to dita -- one
limitation is inability to find a place to put attributes
they require.

Don: Do customers require that attributes be retained when
migrating legacy content?

Chris Wong: Yes -- e.g., attributes that represent
FrameMaker conditions. Haven't seen requests for
general-purpose attributes.

Don: Usability issue -- when an attribute has value of CDATA
or NTOKEN. Often a tools issue when the value of the
attriute must be precisely stated. e.g., when you're
providing a repeatable conditional processing value, or
taxonomy of terms preferred for use within your
organization. When writers compose their own terms for a
data attribute, the taxonomy grows, or there are missed
opportunities for processing.

Paul:  Most tools have hooks for overriding assignment of
attributes.

Don: Where do we go next week?

Joanne: Can we have somebody make statement about categories of
these attributes? Parameters of the attributes we're trying
to define? Processing/filtering, keyword/taxonomic metadata
w/controlled vocabulary? Link to taxonomic engine? Could we
partition the discussion to determine what is settled and
what is not settled? Also legacy attributes? Attributes used
for search?

Paul: Do we want to attack them on a per-attribute type basis
or treat them more generally?

Joanne: If we don't clearly state the requirements of what people
might want to do, we might miss something.

Don: Even if we create a general attribute declaration
mechanism, this does not create an architected way to treat
those attributes. e.g. intent-based design, people would
need to design their own processing.

Categorize to recommend standard implementations of
attributes in those categories.

Bruce Esrig: Want to hook into specialized processing for
attributes that are not acted on by the core kit.
Don: perhaps support fallback processing.

Joanne: Can somebody make post?

Paul: I can post. Note that the scope of XML attributes is
unlimited. However, there are more and less common patterns
that we could document.

Joanne: Specify areas, give people guidance in each area.

Paul Prescod: ACTION ITEM -- post summary of categories for
legacy attributes. 

Don: This also creates vendor opportunity for fulfillment.

Don Day  2005-08-17 02:56 GMT
Satisfied by message to the TC list, http://lists.oasis-open.org/archives/dita/200508/msg00045.html

View Details:
http://www.oasis-open.org/apps/org/workgroup/dita/members/action_item.php?action_item_id=998



PLEASE NOTE:  If the above links do not work for you, your email application
may be breaking the link into two pieces.  You may be able to copy and paste
the entire link address into the address field of your web browser.

- OASIS Open Administration


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