headers
Joel M. Halpern | 2 Jan 2008 15:09

Re: Model draft

There appear to be two issues you are raising with the name space
declaration in this document.  One issue is whether the version goes
before or after the model scoping.  Because the schema and its semantics
relate to the protocol as well as the model, it seemed to go in the
order we have it (version, lfmmodel.)  However, after reading your
comment and thinking about it, I suspect that you are correct about the
ordering, and it should be lfbmodel then 1.0.

The second issue appears to be our use of an http uri rather than a
field delimited urn as the namespace.  The use of HTTP URIs seems fully
conformant.  And the use of web space URIs seems recommended by RFC
3470.  The use of URNs for namespaces is offered there as a fallback
alternative.  So it is not clear to me what the problem is with our usage.

Yours,
Joel M. Halpern

tom.petch wrote:
> I think that the URIs are not quite right yet.
> 
> As per RFC3688, the targetNamespace should be a urn, eg
> 
>  targetNamespace="urn:ietf:params:xml:ns:forces:lfbmodel:1.0"
> 
> and the schema needs a name if it is to be registered with IANA, eg
> 
> "urn:ietf:params:xml:schema:forces:xxx:1.0"
>
(Continue reading)

Permalink | Reply | 3 comments |
headers
tom.petch | 4 Jan 2008 14:20

urn was Re: Model draft

----- Original Message -----
From: "Joel M. Halpern" <joel <at> stevecrocker.com>
To: "tom.petch" <cfinss <at> dial.pipex.com>
Cc: <FORCES <at> PEACH.EASE.LSOFT.COM>
Sent: Wednesday, January 02, 2008 3:09 PM
Subject: Re: Model draft

> There appear to be two issues you are raising with the name space
> declaration in this document.  One issue is whether the version goes
> before or after the model scoping.  Because the schema and its semantics
> relate to the protocol as well as the model, it seemed to go in the
> order we have it (version, lfmmodel.)  However, after reading your
> comment and thinking about it, I suspect that you are correct about the
> ordering, and it should be lfbmodel then 1.0.
>
> The second issue appears to be our use of an http uri rather than a
> field delimited urn as the namespace.  The use of HTTP URIs seems fully
> conformant.  And the use of web space URIs seems recommended by RFC
> 3470.  The use of URNs for namespaces is offered there as a fallback
> alternative.  So it is not clear to me what the problem is with our usage.
>

Not a big problem, perhaps not even little one.  I agree that HTTP URIs are
recommended by RFC3470 but there is a reference there to ongoing work in an I-D
that later became RFC3688, so for me, RFC3688 trumps RFC2470 - and there, as I
read it, urn are recommended.  Certainly I see a lot of urn and cannot recall
when I last saw a HTTP URI, apart from here.  I will ask on apps-discuss and
come back to you.

Tom Petch
(Continue reading)

Permalink | Reply | 2 comments |
headers
tom.petch | 4 Jan 2008 14:35

miscellaneous comments was Re: Model draft

Some comments, prefixed with **+, that do not relate to terminology:-)

3.2.   Logical Functional Block (LFB) Modeling
   An LFB can have one or more inputs, each of which takes a packet P,
   and optionally metadata M; and produces one or more outputs, each of
   which carries a packet P', and optionally metadata M'.

**+ I think that this is too restrictive; s3 says that output may be metadata
only.

4.2.  <LFBLibrary> Element
   In addition to the above main elements, a library document can import

**+ is this an XML import or XML include or both or neither? (this has
implications on namespaces)

4.5.4.  <struct> Element to Define Structures
   In
   addition, the component declaration contains the name of the
   component, a synopsis, an optional description,

**+ I see no <description> in the XML for <component> in <structType> but one is
present in <LFBComponentsType> ; is this intended?

4.5.6.  <alias> Element
   The target of a component declared by an >alias> element is
**+ <alias>

    Details of the alias property structure are described in the section
   of this document on properties.
(Continue reading)

Permalink | Reply | 5 comments |
headers
tom.petch | 4 Jan 2008 15:19

terminology was Re: Model draft

----- Original Message -----
From: "Joel M. Halpern" <jmh <at> joelhalpern.com>
To: "tom.petch" <cfinss <at> dial.pipex.com>
Sent: Wednesday, January 02, 2008 2:59 PM
Subject: Re: Model draft

> I can well believe that the terms as used in S1 could be clearer.
> I have no problem trying to clean up hierarchy, layer, abstraction, and
> level.  I'm not sure it will help much, but I am willing to try.
>

Joel,

let me start again on terminology

I think that the change is terminology is excellent, much easier to follow.
Back in August, you posted to the list that you would come back with how many
new terms you needed, but I missed - and perhaps miss - that.

I think the new terminology does show up some inconsistent usage, and yes I will
propose text, but need to understand more first.  (I find
myself having to reverse engineer the XSD in order to understand the text, and
that should not happen:-) .  s.4 is easier to follow, for all its level of
detail, than the overview in s.3 and again, I think that this should not happen.
I do see a value in being able to read and understand s.3 and not needing to go
further, whereas if you need the level of detail in the whole document, then
yes, you will put in as many weeks as it takes and will get there.

I am referring to the terms: capability, capacity, component, configuration,
operational, state.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Joel M. Halpern | 5 Jan 2008 04:32

Re: miscellaneous comments was Re: Model draft

Response to questions in line.

tom.petch wrote:
> Some comments, prefixed with **+, that do not relate to terminology:-)
> 
> 
> 3.2.   Logical Functional Block (LFB) Modeling
>    An LFB can have one or more inputs, each of which takes a packet P,
>    and optionally metadata M; and produces one or more outputs, each of
>    which carries a packet P', and optionally metadata M'.
> 
> **+ I think that this is too restrictive; s3 says that output may be metadata
> only.
Yes, this text is too restrictive.  There are multiple cases of input or 
output where the "packet" is empty.  I have to think whether it is 
better to refer to a conceptually empty packet, or an omitted packet. 
(The reason it doesn't matter much is that this kind of case has to be 
called out in the descriptive portion of the LFB definition, so the only 
question is how we describe it.)
> 
> 
> 4.2.  <LFBLibrary> Element
>    In addition to the above main elements, a library document can import
> 
> **+ is this an XML import or XML include or both or neither? (this has
> implications on namespaces)
This is neither an XML import or an XML include.  It is an LFB library 
import, <load>  It makes a set of definitions available to the entity 
processing the library, both as classes (if any) and as types, etc. 
This would primarily be done to make sure that datatypes (including
(Continue reading)

Permalink | Reply | 4 comments |
headers
Joel M. Halpern | 5 Jan 2008 04:33

Re: terminology was Re: Model draft

[I sent the reply below to Tom earlier today, but could not send it to 
the list until now.]

I believe that you are correct.
Component includes both <component> (in LFBs and structs) and
<capability> elements.
So yes, you have understood what the document is saying.
And yes, what you have written needs to be said somewhere in the
document.  Probably along with fixing some references to become
"Component".  (If I had enough good words, I would just use lower case
component for the english, and have some other words for the LFB and
struct pieces.  But I am all out of words.)
One idea would be to use <component> in the <capabilities> section, so
that there are capability components, other LFB components, and struct
components.  Would that work?

Yours,
Joel

tom.petch wrote:
> ----- Original Message -----
> From: "Joel M. Halpern" <jmh <at> joelhalpern.com>
> To: "tom.petch" <cfinss <at> dial.pipex.com>
> Sent: Wednesday, January 02, 2008 2:59 PM
> Subject: Re: Model draft
> 
> 
>> I can well believe that the terms as used in S1 could be clearer.
>> I have no problem trying to clean up hierarchy, layer, abstraction, and
>> level.  I'm not sure it will help much, but I am willing to try.
(Continue reading)

Permalink | Reply | 4 comments |
headers
tom.petch | 7 Jan 2008 11:48

Re: miscellaneous comments was Re: Model draft

Joel

cutting the ones I think we agree on, comments in line

Tom Petch.

----- Original Message -----
From: "Joel M. Halpern" <joel <at> stevecrocker.com>
To: "tom.petch" <cfinss <at> dial.pipex.com>
Cc: <FORCES <at> PEACH.EASE.LSOFT.COM>
Sent: Saturday, January 05, 2008 4:32 AM
Subject: Re: miscellaneous comments was Re: Model draft

> Response to questions in line.
>
> tom.petch wrote:
> > Some comments, prefixed with **+, that do not relate to terminology:-)
> >
> >

> >
> > **+ is this an XML import or XML include or both or neither? (this has
> > implications on namespaces)
> This is neither an XML import or an XML include.  It is an LFB library
> import, <load>  It makes a set of definitions available to the entity
> processing the library, both as classes (if any) and as types, etc.
> This would primarily be done to make sure that datatypes (including
> metadata) that are being used, or strctures or LFB classes that are
> being extended / revised are available.
>
(Continue reading)

Permalink | Reply | 3 comments |
headers
tom.petch | 7 Jan 2008 12:06

URI for XML schema and namespace wasRe: urn was Re: Model draft

I said I would raise the question of what to use to name a namespace on the Apps
Discuss list and I did, under the Subject above.  The discussion was most
interesting with perhaps the most significant view being that of Chris Newman,
as follows
============================================
Date: Fri, 04 Jan 2008 15:46:02 -0800
From: Chris Newman <Chris.Newman <at> Sun.COM>

As Applications Area Director, I'm not aware of anyone ever asking for that.

I'm holding a discuss position on:
   draft-narten-iana-considerations-rfc2434bis-08
because the present text forbids use of IANA URLs and I consider that an
unacceptable new restriction for IANA considerations.

Current IETF practice discourages use of IANA URLs in IETF specifications.
However, we have one case, RFC 4790, where stable iana.org http URLs are
provided to registry elements and that was done with IANA's permission.  In that
case, the registry was created to be useful to both the IETF and the W3C. The
stable http URLs make the W3C happier so it was worth doing that way.

I would support a similar approach for iana.org http XML namespaces if someone
spent the time to write up the rules and get IANA's consent.

Using an ietf.org http URIs for XML namespaces is a bad idea.  The IETF has
deliberately kept the registry function for our standards separate and I
consider that a feature.  Also, ietf.org is operated by the Secretariat
function so using that domain for registrations would require additional (and
more expensive) coordination than iana.org.  It _might_ be feasible to set up a
redirect from ietf.org to iana.org for XML namespaces, but I worry that's just
(Continue reading)

Permalink | Reply | 1 comment |
headers
McCann Peter-A001034 | 7 Jan 2008 22:06

Some editorial nits on the model draft

There are a few misplaced angle brackets in the document.

Section 4.5.6:  >alias> SHOULD BE <alias>

Section 4.7:    < version> SHOULD BE <version>
                <LFBClassDef< SHOULD BE <LFBClassDef>

Section 4.7.2:  <inputPort > SHOULD BE <inputPort>
                < expectation> SHOULD BE <expectation>
                <inputPorts< SHOULD BE <inputPorts>

Throughout the document:
  REPLACE "a metadata" with "a metadatum"

Section 4.7.2:

  ot the corresponding <ref> element
SHOULD BE:
  of the corresponding <ref> element

Section 4.7.3: < outputPort> SHOULD BE <outputPort>

Section 4.7.6.1:

  ealier
SHOULD BE:
  earlier

      The example event Gah10field1 illustrates the
      how the column
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joel M. Halpern | 7 Jan 2008 23:43

Re: miscellaneous comments was Re: Model draft

Thanks.  Comments where further clarification helps / is needed.
(Exchange is between Tom Petch and myself.  Headers removed as there are 
only two conversants.)

tom.petch wrote:
> Joel
> 
> cutting the ones I think we agree on, comments in line
> 
> Tom Petch.
> 
> 

>>> 4.7.3.  <outputPorts> Element to Define LFB Outputs
>>>    This is indicated by a "yes" value
>>>    (the default value is "no").
>>>
>>> **+ The XML has default of 0 - I see no indication which is yes and which
> no;
>>> some XML users define a truthValue, of yes or no.
>> Not sure what you are asking for.  The attribute definition says that
>> the attribute is optional and has a default of "no".  Folks have run
>> this through XML vereifiers and it seems okay.
>>
> 
> What I am looking at in the Schema is
>  <xsd:simpleType name="booleanType">
>         <xsd:restriction base="xsd:string">
>           <xsd:enumeration value="0"/>
>           <xsd:enumeration value="1"/>
(Continue reading)

Permalink | Reply | 1 comment |

Gmane