OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cgmo-webcgm message

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


Subject: Re[2]: [cgmo-webcgm] Issue CL-d5: 2.3.2 WebCGM defined group types


I favor b)

-- 
 Benoit   mailto:benoit@itedo.com

This e-mail and any attachments are confidential and may be protected
by legal privilege. If you are not the intended recipient, be aware
that any disclosure, copying, distribution or use of this e-mail or
any attachment is prohibited. If you have received this e-mail in
error, please notify us immediately by returning it to the sender and
delete this copy from your system. Thank you for your cooperation. 



Wednesday, May 3, 2006, 10:17:10 AM, you wrote:

> [2 of 2]

> At 04:32 PM 5/2/2006 -0700, Cruikshank, David W wrote:
>>  Confirm your agreement with Ben's assessment of this issue.

> I agree with most of what Benoit says.  Exception:  "Either we have 
> duplicate information (that's my opinion, I think 2.3.2 is saying too much)
> and/or we should like from 2.3.2 to the _real_ definition of all these APS".

> Our original motivation with Ch.2, which is labelled as informative or
> non-normative, is to give a quickly readable understanding of what WebCGM
> is about.  As I read 2.3.2, I doubt that we could have much less detail and
> still give any inkling of the purpose of the various defined objects --
> there is only a single sentence per APS type.  I don't mind if we have more
> obvious links to the individual normative sections in Ch.3 (there is only a
> single "This section is informative" at the start of Ch.2).

> What does the TC want?

> a.) rewrite for less detail
> b.) add links to Ch.3 on a subsection or object basis
> c.) do nothing
> d.) other

> I guess I favor #b or #c.

> -Lofton.



>>Technical Fellow - Graphics/Digital Data Interchange
>>Boeing Commercial Airplane
>>206.544.3560, fax 206.662.3734  <-- NEW NUMBERS
>>david.w.cruikshank@boeing.com
>>
>>-----Original Message-----
>>From: Benoit Bezaire [mailto:benoit@itedo.com]
>>Sent: Friday, April 21, 2006 7:36 AM
>>To: CGM Open WebCGM TC
>>Subject: [cgmo-webcgm] Issue CL-d5: 2.3.2 WebCGM defined group types
>>
>>CL wrote: "[[[ 2.3.2 WebCGM defined group types para - (paragraph) an
>>APS type to facilitate text search within graphics, in cases such as
>>multi-element, multi-line text, and other cases (e.g., polygonized text)
>>where text search might otherwise be difficult (or impossible).]]]
>>
>>Is that a block, in terms of bidi and in terms of text to speech? Is
>>subpara a block or an inline (span)?"
>>
>>---
>>
>>Interestingly enough Chris' comment comes in after reading section
>>2.3.2 and not 3.2.1.3
>>
>>To me, this identifies a problem in the spec. Either we have duplicate
>>information (that's my opinion, I think 2.3.2 is saying too much) and/or
>>we should like from 2.3.2 to the _real_ definition of all these APS
>>(i.e., 3.2...).
>>
>>Now, assuming a reader has the same question after reading 3.2.1.3 and
>>3.2.1.4...  Note: my understanding of RESTRICTED TEXT and APPEND TEXT is
>>limited.
>>
>>Q: Is that a block, in terms of bidi and in terms of text to speech?
>>A: 'para' is not a text element, it is a grouping mechanism which allows
>>certain object attributes; more specifically the 'content'
>>attribute for this particular object type (see 3.2.1.3). RESTRICTED TEXT
>>and APPEND TEXT define the WebCGM text features (see T.19.5, T.19.6).
>>
>>Q: Is subpara a block or an inline (span)?
>>A: 'subpara' like 'para' is not a text element, but a grouping object
>>which allows for the 'content' attribute to be specified. (see
>>3.2.1.4)
>>
>>Regards,
>>
>>--
>>  Benoit   mailto:benoit@itedo.com
>>
>>This e-mail and any attachments are confidential and may be protected by
>>legal privilege. If you are not the intended recipient, be aware that
>>any disclosure, copying, distribution or use of this e-mail or any
>>attachment is prohibited. If you have received this e-mail in error,
>>please notify us immediately by returning it to the sender and delete
>>this copy from your system. Thank you for your cooperation.




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