Re[2]: [cgmo-webcgm] ISSUE: is apsid an attribute?

[Lofton Henderson <lofton@rockynet.com>]

[...Attn implementors Ulrich, Don, Forrest...]

I'd like to hear from the other DOM implementors also:  Ulrich, Don, 
Forrest.  But I don't mind if we go with apsid is an 'attribute'.  It's not 
a big deal exactly how we define the CGM--DOM mapping, as long as we define 
it clearly.

Now, here is another small, related question.  hasAttributes() and 
'attributes' are defined on WebCGMNode.  We are resolving what they mean 
for APS nodes.  What do they mean for the other four node types?

** Picture -- does picture have any (WebCGMNode) 
'attributes'?  (WebCGMPicture defines individual 'pictid', 'width', 
'height' attributes.)

** Metadata -- is it correct that Metadata nodes have no 'attributes' and 
hasAttributes() is always false, but rather everything would appear under 
hasAttributesNS()?

** Text (Nothing -- CDATA text nodes have no attributes)

** Attr (Nothing -- attributes don't have attributes)

Would it be useful to make a little table like the nodeName/nodeValue 
table, for 'attributes', hasAttributes() [and hasAttributesNS(), 
getAttributeNS,...]?

Regards,
-Lofton.

At 10:46 AM 7/8/2005 -0400, Benoit Bezaire wrote:
>Dieter makes a good point... From a DOM perspective, why should 'name'
>be an attribute but not the APS id?
>
>--
>  Benoit   mailto:benoit@itedo.com
>
>
>Friday, July 8, 2005, 10:35:45 AM, Dieter wrote:
>
>DW> Lofton,
>
>DW> see below
>
> >> -----Original Message-----
> >> From: Lofton Henderson [mailto:lofton@rockynet.com]
> >> Sent: Friday, July 08, 2005 4:29 PM
> >> To: cgmo-webcgm@lists.oasis-open.org
> >> Subject: Re: [cgmo-webcgm] ISSUE: is apsid an attribute?
> >>
> >>
> >> Expressing my own (mild) preference...
> >>
> >> I guess I'd prefer that apsid is *not* included in the
> >> 'attributes' of the
> >> WebCGMNode interface of DOM.  Reasons:
> >>
> >> -- myAps.apsId already gives quick and immediate access to the
> >> apsid.  ('apsId' is the attribute on the WebCGMAppStructure interface).
> >>
> >> -- if we take the interpretation that apsid is *not* one of the
> >> attributes,
> >> myAps.hasAttributes() would return false unless there are **APS
> >> Attributes** (in the metafile sense) in the given target APS.
> >> Otherwise it
> >> would always return true, and you would have to look at
> >> myAps.attributes.count to see if there are any APS Attributes --
> >> if we were
> >> to take the interpretation that apsid is one of the 'attributes', then
> >> count is always at least 1, and you'd have to check for >1 to
> >> determine if
> >> there are any APS Attributes.
> >>
> >> I'm having trouble thinking of any *strong* arguments one way or the
> >> other.  Does anyone see any strong arguments for having apsid be
> >> one of the
> >> 'attributes' of the WebCGMNode interface?
>
>DW> Common sense among script writers, I guess.
>DW> There is no other case that I am aware of where there is an ID on an
>DW> element, and it is not an attribute.
>DW> If we treat it as an attribute, everybody will understand easily, and
>DW> will be able to work with it without further explanation.
>DW> Otherwise (if we don't make it an attribute), we have the following
>DW> situation:
>DW> In the XCF, apsID is clearly an attribute,however, in the DOM, it is
>DW> not an attribute, is is something different. This leads to the situation
>DW> that binding between XCF and CGM file happens between an XML attribute
>DW> on the one side and a non-attribute on the CGM side.
>DW> And then we start explaining that apsID is an attribute, but it is not
>DW> really an attribute, it is just a parameter to the Begin APS element...
>DW> In addition, "apsName" (sp?) IS an attribute, so there we bind from
>DW> an XML attribute to a CGM attribute.
>DW> All in all, quite confusing. Hardly understandable if you don't know
>DW> CGM inside out.
>
>DW> Cheers,
>DW> Dieter
>
>
> >>
> >> Cheers,
> >> -Lofton.
> >>
> >> At 07:20 PM 7/7/2005 -0600, Lofton Henderson wrote:
> >> >Source:  editors / test writers.
> >> >
> >> >ISSUE:  does the apsid parameter of the BegAps element show up as an
> >> >attribute in the DOM?
> >> >
> >> >DESCRIPTION:
> >> >
> >> >WebCGMNode contains a boolean method, hasAttributes(), and an
> >> attribute of
> >> >type node-list, 'attributes'.  What qualifies as an attribute is not
> >> >defined anywhere.  The obvious thing that comes to mind is APS
> >> Attributes
> >> >(on APS nodes).  The text says the value of 'attributes' will be null in
> >> >the case that the WebCGMNode has no attributes.
> >> >
> >> >WebCGMAppStructure, which inherits from WebCGMNode, has an additional
> >> >attribute, 'apsId'.  In metafiles, the apsid is a parameter on
> >> the BegAps
> >> >element (along with the 'type' and the 'inheritance flag' parameters).
> >> >
> >> >The initial code of the test Node-attr.html shows that the apsid
> >> is being
> >> >treated in the test as if it is an 'attribute'.
> >> >
> >> >So should DOM return the metafile apsid as an 'attribute' (WebCGMNode
> >> >interface), or only as the 'apsId' on the WebCGMAppStructure
> >> interface, or
> >> >both?
> >> >
> >> >It seems to me that the way we designed the interfaces and their
> >> >methods/attributes seems to hint at "only 'apsId'".  On the other hand,
> >> >Benoit seems to remember some past decision for 'attribute' or
> >> "both".  If
> >> >that is the case, note that hasAttributes() will always return
> >> true for an
> >> >APS node (by far its most usual usage, if not the only usage), and
> >> >'attributes' will always have a count of at least 1.  Also note that in
> >> >XCF, apsid is a required XML attribute on all the APS elements (and the
> >> >bindById, of course).
> >> >
> >> >It is not really critical *how* we answer it.  We have some
> >> freedom in how
> >> >we map the structured metafile instance onto an XML-like DOM
> >> tree.  But it
> >> >is critical that we have a clear answer and document it.
> >> >
> >> >ALTERNATIVES:
> >> >Alt.1:  'apsId' only
> >> >Alt.2:  'attribute' only (which would mean eliminate 'apsId')
> >> >Alt.3:  both
> >> >
> >> >RECOMMENDATION:  none yet, TC should discuss.  Implementors,
> >> what have you
> >> >done?
> >> >
> >> >Regards,
> >> >-Lofton.