Re: terminology wa Re: XML basics Re: LC model draft draft-ietf-forces-model-07.txt

I think that I understand the question.
The IDs used in path-data TLVs are not just any arbitrary XML 
elements that happen to have elementID attributes.
They must be <attribute> <capability> or <event> components.
This is actually implicit in the fact that other XML "elements" (in 
the XML sense) are not legal in the document.
When we get the terminology straightened out in both the model and 
the protocol draft, this potential confusion should disappear.

Yours,
Joel

At 04:17 AM 11/9/2006, tom.petch wrote:
>----- Original Message -----
>From: "Joel M. Halpern" <[email protected]>
>To: <[email protected]>
>Sent: Wednesday, November 08, 2006 6:36 PM
>Subject: Re: terminology wa Re: XML basics Re: LC model draft
>draft-ietf-forces-model-07.txt
>
>
> > All pieces of information that the ForCES protocol can manipulate are
> > described in LFB Class definitions using the LFB components defined
> > in the schema (currently called capability, attribute, and event,
> > along with element properties.)
> > Given the existence of documentation elements, there is no reason to
> > use arbitrary XML in the definitions, and the schema does not permit
> > arbitrary elements.
> >
>Ok so far but I am asking more.  If a CE wishes to access a piece of data by
>itself (not as part of a larger structure) using PATH-DATA-TLV, then must that
>piece of data be defined as an XML element as opposed to being 
>defined as an XML
>attribute?
>
>This is fundamental to my understanding of how -model and -protocol link
>together and I do not see it clearly stated.  s7.6 may or may not say this
>depending on which of the many possible interpretations is given to the terms
>'element' and 'identifier':-(
>
>Thus s7.6 might be reworded as
>    "The FE Model provides for the definition of LFB Classes.  Each 
> LFB Class has
>a globally unique identifier, assigned by IANA.  Each instance of a particular
>LFB Class within an NE also has a unique identifier.  Data elements 
>that can be
>accessed by the protocol using a PATH-DATA-TLV are defined as XML elements and
>each is assigned an identifier (using the XML attribute "elementID= ") that is
>unique within an LFB Class.  The combination of LFB Class identifier, LFB
>instance identifier and element identifier(s) is used by the protocol to
>reference the LFB information in the protocol operations. "
>
>Have I got it? ((skating over for the moment elementIDs in events and
>structures)
>
>Tom Petch
>
> > (This may suggest to some a compatibility issue.  The idea is that if
> > the schema is ever extended then old definitions will be compatible
> > with the new schema, but new definitions will not be compatible with
> > the old schema.  Given the need for semantic knowledge for anything
> > making uses of LFB class definitions, this does not seem to be a problem.)
> >
> > Yours,
> > Joel M. Halpern
> >
> > At 09:49 AM 11/8/2006, tom.petch wrote:
> > >In general, most of what can be done in XML can be done by using XML
> > >attributes
> > >of XML elements or by using XML elements per se. So a second 
> point is, I am
> > >unclear in -model whether the intention is that all pieces of data
> > >that a CE can
> > >read or write are expressed as XML elements or are some of them XML
>attributes
> > >(of XML elements).  This has ramifications for identifiers and namespaces
> > >and -protocol.