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: Issue #20 (was [dita] Really two issues?)



Comments below

Michael Priestley
mpriestl@ca.ibm.com


paul.prescod@blastradius.com wrote on 07/26/2005 08:02:09 AM:

> Mr. Paul Prescod added the following comment to the IssueNumber20.
> html document in the OASIS Darwin Information Typing Architecture
> (DITA) TC Group.
>
> Perhaps this is really a few issues conflated into one.
>
> Issue one is allowing new attributes on specialized elements.


Actually this is not treated in the feature. The feature is specifically for adding new global attributes intended for use as filtering/flagging attributes (what are called "metadata attributes" in the architectural spec). This is suggested to be done via an extension of domain specialization. That extension might also be applicable to other attributes, but not without some work.

Adding new attributes to a new element would presumably be an extension of structural specialization. I can imagine there would be ways to accomodate this (equivalent needs for preserving the attribute values in some processable form through the trials and tribulations of generalization and respecialization) but it's not in scope for this feature I think.

>
> Issue two is treating some attributes as filtering attributes. One
> can imagine hundreds of "extension attributes" that have nothing to
> do with filtering.


Absolutely. The current way to determine which attributes to treat as filtering attributes is by listing (they are enumerated in the architectural spec). The proposed way is via specialization (make them all specializations of an ancestral props attribute; any new filtering attribute would need to inherit from that base attribute as well in order to be considered a filtering attribute).
>
> Issue three is defining standards (ditaval?) for managing
> conditional attributes.


This is already documented in non-normative fashion in the spec, and in use by the toolkit.

>
> Also: I feel it is very important to be able to add attributes
> _without_ specializing the elements that the attributes reside on.
> I'm not sure if you intended this.


It is in fact all I intended at this point :-) All the current feature describes is how to add new global attributes via substitution (ie wherever @audience is currently allowed, the feature would allow expansion into @role, @skill, etc.).

I will update the feature to hopefully make this all clearer.

>
>
> View Document Details and Comments:
> http://www.oasis-open.org/apps/org/workgroup/dita/document.php?
> document_id=13756
>
> Download Document:  
> http://www.oasis-open.org/apps/org/workgroup/dita/download.
> php/13756/IssueNumber20.html
>
> 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.
>
> - Administration


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