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

"tom.petch" <[email protected]> Mon, 30 Oct 2006 09:41:12 +0100
Newsgroups gmane.ietf.forces
Message-ID <000b01c6fbff$82c7c400$0601a8c0@pc6>
---- Original Message -----
From: "Joel M. Halpern" <[email protected]>
To: <[email protected]>
Sent: Friday, October 27, 2006 11:13 PM
Subject: Re: XML basics Re: LC model draft draft-ietf-forces-model-07.txt


> Sorry, unlike the other comments, you have lost me on this one.
> The only XML permitted by the model is XML which conforms to the schema.
> And there are no ##any clauses, so that is quite a tight restriction.
> (unlike some of the other protocols that are using XML.)
>
That is fine but I think s4 needs to spell that out more explicitly; I only sort
of got the message.  Elsewhere, many - most? - users of XML I see have multiple
schema so it might be the expectation of vendors creating private LFB Class that
they can extend the schema as they choose.

Is there any technical way of limiting documents to just this schema (plus the
XML one)?  I do not know of any.

Two consequences.   First, it becomes more likely that there will be changes
needed to the LFB schema in its early days, needs for new attributes or
elements, which in turn will be easier to achieve if the schema is in a separate
document as opposed to part of a large -model document (pork barrel politics).

Second, which version of the XML Schema are you usiing/ I note that this I-D
references [14] the 2001 version (in the text but not in the URL) while most I-D
now reference 2004 or 2006; doubtless there will be more versions..

I think this issue also extends to data types.  You list built-in atomic data
types  (s4.5) which is a subset of those in the XML Schema; are the others
positively excluded?  Again, I sort of get that message but think it should be
stated more explicitly

Tom Petch
>
> Also remember that the XML is not part of the protocol, but only part
> of the semantic definition of the LFB classes.  THE XML schema is
> actually a definition of an XML subset usex\d to define LFB
> classes.  Those class definitions are not sent or received by the
> ForCES protocol, but only used by the protocol to understand the
> meaning of the identifiers.
>
> Yours,
> Joel M. Halpern
>
> At 12:30 PM 10/27/2006, tom.petch wrote:
> >Thinking some more about not understanding what is permitted with keys (and
> >prompted by reading another XML data model I-D), I would like to see
> >more about
> >the usage of XML.  This I-D dives straight into ForCES technology and
explains
> >that at length, but lacks much in the way of what XML is and is not
permitted.
> >
> >Keys are one example.  Another is the question I raised earlier about Schema
;
> >there is a Schema but is it the Schema? (most XML I know has several with
> >consequent namespace issues).  Basic data types is another; I saw a
> >statemant in
> >another I-D that there are 44 in XML Schema which left me wondering about the
> >list in -model.  Schema versioning? much about LFB Class versioning but
Schema
> >have versions too.  Namespaces, the use of elementID, NMTOKEN ...
> >
> >I have a sense of unspoken assumptions about which bits of XML will be used,
> >which not, and
> >would like more explicitness.
> >
> >Which is all I can produce by way of last call comments for the moment.
> >
> >Tom Petch
> >
> >
> >----- Original Message -----
> >From: "Patrick Droz" <[email protected]>
> >To: <[email protected]>
> >Sent: Friday, October 13, 2006 10:36 AM
> >Subject: LC model draft draft-ietf-forces-model-07.txt
> >
> >
> > > I would like to issue last call on the model draft. As this is
> > > a fairly large document the LC will last for 3 weeks and will
> > > therefore end just before the next IETF. It is draft:
> > > draft-ietf-forces-model-07.txt
> > > and can be found at:
> > > http://www.ietf.org/internet-drafts/draft-ietf-forces-model-07.txt
> > >
> > > A number of people have indicated that if the document is in
> > > LC they would thoroughly review the document. I hope people will
> > > stick to their promises.
> > >
> > > Regards,
> > > Patrick
> > >
> > >
> > >