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] DITA v1.2 Review | Propagating attribute values


Hi Eliot,

I am still unclear that whether such a behavior cannot be defined because of the processor not being able to distinguish between such values or some other reason.

In case, it is due to the processor, than I would say that is a implementation-level thing that a processor can take care of. Also, as you mentioned there are some that are able to do so now as well. Also, sometimes the need causes the implementations to happen :).  So if we define such a behavior, may be such implementations become common.

Regards,
Tarun Garg | Adobe Systems | +91-120-2444711 | tarung@adobe.com

-----Original Message-----
From: Eliot Kimber [mailto:ekimber@reallysi.com] 
Sent: Wednesday, September 22, 2010 4:36 PM
To: Tarun Garg; dita
Subject: Re: [dita] DITA v1.2 Review | Propagating attribute values

Tarun,

I think we've resolved the issue of attribute propagation by key definitions
but I don't think we ever responded to the details of this specific note.

Namely, whether or not an attribute is specified in a document instance or
is defaulted in a DTD or schema can have no effect on processing because
after parsing the two cases are indistinguishable, meaning a processor
either cannot know how the attribute value came to be (because the parser
simply reports the attribute value, not how it was specified) or the
processor can know (e.g., an XML editor) but must ignore that knowledge.

Thus it would not be possible for the DITA standard to define behaviors
based on whether or not a given attribute was defined as a DTD- or
schema-provided default.

Or said another way, all DITA processing must work for documents that have
no associated DTD or XSD (or other form of document constraint
specification) meaning that for such documents all attributes are either
specified or not specified in the instance, because that's all you have.

Cheers,

Eliot

On 8/25/10 3:24 AM, "Tarun Garg" <tarung@adobe.com> wrote:

> The attribute values get propagated:
> ·        For Keys ­ from key-defining element to key-referencing element.
> 
> ·        For Conref ­ from referenced element to referencing element.
> 
>  
> An attribute value can be specified through two ways:
> ·        In the DTD; as the default/fixed value.
> 
> ·        In the XML instance.
> 
>  
> So, while propagating the attribute values, I think the values specified in
> the XML instance itself shall only be considered for propagation. One of the
> reason I think so, is that the value specified in the DTD is already available
> in most cases and need not be propagated. Apart from this, the value specified
> in the XML instance, indicates the user intention to assign a specific value
> to an element & that needs to be propagated.
>  
>  
>  
> One specific case for this relates to public review comment #C011
> (http://lists.oasis-open.org/archives/dita-comment/201007/msg00016.html).
>  
> For a <keydef> element the default value of @processing-role is define as
> ³resource-only² through the DTD. Now, there is a possibility that a user
> assigns value to @processing-role explicitly in the xml. These two cases are
> different and I think the propagation of the value shall happen differently
> for these two scenarios as follows.
> ·        If the value is defined through DTD ­ It shall NOT be propagated from
> key-defining to key-referencing element.
> 
> ·        If the value is explicitly specified in the XML - It shall be
> propagated from key-defining to key-referencing element.
> 
> This is so because, in general for key-defining element, the @processing-role
> is controlled through DTD because, the purpose of the element is clear and per
> the standard. Now, if a user is specifying a value in the XML explicitly, then
> I assume the user wants some different behavior and hence, the value shall be
> propagated.
>  
> Regards,
> Tarun Garg | Adobe Systems | +91-120-2444711 | tarung@adobe.com

-- 
Eliot Kimber
Senior Solutions Architect
"Bringing Strategy, Content, and Technology Together"
Main: 512.554.9368
www.reallysi.com
www.rsuitecms.com



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