search

osgi / bugzilla-archive

Archive of OSGi Alliance Specification Bugzilla bugs. The Specification Bugzilla system was decommissioned with the move to GitHub. The issues in this repository are imported from the Specification Bugzilla system for archival purposes.
0 stars 1 forks source link

[RFC149] review confirmation for Sec 6.4.3 #1708

Closed bjhargrave closed 13 years ago

bjhargrave commented 13 years ago

Original bug ID: BZ#1840 From: Ikuo Yamasaki <yamasaki.ikuo@lab.ntt.co.jp> Reported version: R4 V4.3

bjhargrave commented 13 years ago

Comment author: Ikuo Yamasaki <yamasaki.ikuo@lab.ntt.co.jp>

In order to track the issue, this bug is opened.

Sec 6.4.3 "Responsibility on XML Values Handling" in the latest RFC149 has the following description.

-----begin quote-----

Evgeni commented "Do we really need it? Those rules are TR (XML) specific and they are out of specification scope."

William, could you provide your opinion what to write in RFC149 ? Concrete sentence would be appreciated.

-----begin quote-----

Evgeni commented "OK, but it must be said by TR spec."

William, could you provide your opinion what to write in RFC149 ? Concrete sentence would be appreciated.

bjhargrave commented 13 years ago

Comment author: william.lupton@pace.com

In order to track the issue, this bug is opened.

Sec 6.4.3 "Responsibility on XML Values Handling" in the latest RFC149 has the following description.

-----begin quote-----

  • The simple rule is that this whitespace processing needs to be done for all but “xs:string” -----end quote-----

Evgeni commented "Do we really need it? Those rules are TR (XML) specific and they are out of specification scope."

William, could you provide your opinion what to write in RFC149 ? Concrete sentence would be appreciated.

It's tough, because, for example in the XML, “ 2 “ would be a valid integer. So if this is invalid at the DMT level doesn't this need to be stated? I don't think it needs to be a normative requirement though, perhaps just a note? Another example is Boolean. XML Schema allows 0 and “false” (etc). But if DMT requires 0 then isn't it useful to point that out?

BTW, this is the TR-069 PA, so what's wrong with being TR-069-specific?

Here are my proposals for the actual text in the spec. I have pasted the bullet points and put "WL" comments below them:

For handling SetParameterValues RPC, the protocol adapter will extract parameter values from it. • These values can be anything that is valid for the corresponding SOAP data type. • The data type can be inferred from the XML itself via the xsi:type attribute. • The protocol adapter is responsible for collapsing whitespace, as defined by XML Schema [9]., before passing the value to the TR069ParameterValue#getDmtData() or getDmtDataForList() or DmtData constructor. WL: I suggest putting "for all non-string data types" after "collapsing whitespace". Then the "simple rule" bullet point below can be removed.

◦ TR069ParameterValue#getDmtData() or getDmtDataForList() are not responsible for it. WL: The above does no harm but is not necessary.

• The simple rule is that this whitespace processing needs to be done for all but “xs:string” WL: As proposed above, I suggest deleting this.

• The set of valid values is the same as that of the corresponding data type as defined by XML Schema[9].); for example, hexBinary and numeric values cannot contain embedded spaces. WL: The first bullet already implies this. I think that we can lose the example because we can assume that values arriving from the ACS will be valid XML (also I have proposed that this info be given under GPV).

• TR069ParameterValue#getDmtData() or getDmtDataForList() are responsible for handling the value in lexical representation as defined by XML Schema[9].. WL: Does this add anything? I think it can be deleted.

The resulting text might be as follows:

For handling SetParameterValues RPC, the protocol adapter will extract parameter values from it. • These values can be anything that is valid for the corresponding SOAP data type. • The data type can be inferred from the XML itself via the xsi:type attribute. • The protocol adapter is responsible for collapsing whitespace for all non-string data types, as defined by XML Schema [9]., before passing the value to the TR069ParameterValue#getDmtData() or getDmtDataForList() or DmtData constructor.

-----begin quote-----

  • For handling GetParameterValues RPC, the protocol adapter must return GetParameterValuesResponse whose values are canonical representation as defined by TR069, where canonical representation is defined by XML Schema[9]., e.g. upper-case Hex letters in hexBinary, and no leading zeroes in numeric values. -----end quote-----

Evgeni commented "OK, but it must be said by TR spec."

William, could you provide your opinion what to write in RFC149 ? Concrete sentence would be appreciated.

I think it's like the other case. Here of course the canonical representation isn't a requirement, because TR-069 has to accept all valid XML, but “01 23” would still be invalid HexBinary. So again it's a guideline, not a normative requirement.

I think that this is a better place (if we want to mention it at all) to underline that hexBinary and numeric values can't contain embedded spaces, because this IS permitted at the DMTAdmin level (well, for hexBinary; not sure about numeric), so the PA might have to perform special processing.

Possible text:

For handling GetParameterValues RPC, the protocol adapter must return GetParameterValuesResponse whose values are valid for the corresponding SOAP type. Note that this means that hexBinary and numeric values cannot contain embedded spaces.

bjhargrave commented 13 years ago

Comment author: Ikuo Yamasaki <yamasaki.ikuo@lab.ntt.co.jp>

In order to track the issue, this bug is opened.

Sec 6.4.3 "Responsibility on XML Values Handling" in the latest RFC149 has the following description.

-----begin quote-----

  • The simple rule is that this whitespace processing needs to be done for all but “xs:string” -----end quote-----

Evgeni commented "Do we really need it? Those rules are TR (XML) specific and they are out of specification scope."

William, could you provide your opinion what to write in RFC149 ? Concrete sentence would be appreciated.

It's tough, because, for example in the XML, “ 2 “ would be a valid integer. So if this is invalid at the DMT level doesn't this need to be stated? I don't think it needs to be a normative requirement though, perhaps just a note? Another example is Boolean. XML Schema allows 0 and “false” (etc). But if DMT requires 0 then isn't it useful to point that out?

That is why I would like to clarify "TR069ParameterValue#getDmtData() and getDmtDataForList() are responsible for handling the value in lexical representation as defined by XML Schema[9].

BTW, this is the TR-069 PA, so what's wrong with being TR-069-specific?

Here are my proposals for the actual text in the spec. I have pasted the bullet points and put "WL" comments below them:

For handling SetParameterValues RPC, the protocol adapter will extract parameter values from it. • These values can be anything that is valid for the corresponding SOAP data type. • The data type can be inferred from the XML itself via the xsi:type attribute. • The protocol adapter is responsible for collapsing whitespace, as defined by XML Schema [9]., before passing the value to the TR069ParameterValue#getDmtData() or getDmtDataForList() or DmtData constructor. WL: I suggest putting "for all non-string data types" after "collapsing whitespace". Then the "simple rule" bullet point below can be removed.

◦ TR069ParameterValue#getDmtData() or getDmtDataForList() are not responsible for it. WL: The above does no harm but is not necessary.

• The simple rule is that this whitespace processing needs to be done for all but “xs:string” WL: As proposed above, I suggest deleting this.

• The set of valid values is the same as that of the corresponding data type as defined by XML Schema[9].); for example, hexBinary and numeric values cannot contain embedded spaces. WL: The first bullet already implies this. I think that we can lose the example because we can assume that values arriving from the ACS will be valid XML (also I have proposed that this info be given under GPV).

• TR069ParameterValue#getDmtData() or getDmtDataForList() are responsible for handling the value in lexical representation as defined by XML Schema[9].. WL: Does this add anything? I think it can be deleted.

Yes, as I wrote. I think we need to clarify which A or B is responsible for it. A. PA impl except TR069ParameterValue is responsible for it. B. TR069ParameterValue is responsible for it.

The resulting text might be as follows:

For handling SetParameterValues RPC, the protocol adapter will extract parameter values from it. • These values can be anything that is valid for the corresponding SOAP data type. • The data type can be inferred from the XML itself via the xsi:type attribute. • The protocol adapter is responsible for collapsing whitespace for all non-string data types, as defined by XML Schema [9]., before passing the value to the TR069ParameterValue#getDmtData() or getDmtDataForList() or DmtData constructor.

Thank you for your proposal. Taking your comment into account, I would propose the following text:

For handling SetParameterValues RPC, the protocol adapter will extract parameter values from it.

-----begin quote-----

  • For handling GetParameterValues RPC, the protocol adapter must return GetParameterValuesResponse whose values are canonical representation as defined by TR069, where canonical representation is defined by XML Schema[9]., e.g. upper-case Hex letters in hexBinary, and no leading zeroes in numeric values. -----end quote-----

Evgeni commented "OK, but it must be said by TR spec."

William, could you provide your opinion what to write in RFC149 ? Concrete sentence would be appreciated.

I think it's like the other case. Here of course the canonical representation isn't a requirement, because TR-069 has to accept all valid XML, but “01 23” would still be invalid HexBinary. So again it's a guideline, not a normative requirement.

I think that this is a better place (if we want to mention it at all) to underline that hexBinary and numeric values can't contain embedded spaces, because this IS permitted at the DMTAdmin level (well, for hexBinary; not sure about numeric), so the PA might have to perform special processing.

Possible text:

For handling GetParameterValues RPC, the protocol adapter must return GetParameterValuesResponse whose values are valid for the corresponding SOAP type. Note that this means that hexBinary and numeric values cannot contain embedded spaces.

I will apply it.

bjhargrave commented 13 years ago

Comment author: william.lupton@pace.com

• TR069ParameterValue#getDmtData() or getDmtDataForList() are responsible for handling the value in lexical representation as defined by XML Schema[9].. WL: Does this add anything? I think it can be deleted.

Yes, as I wrote. I think we need to clarify which A or B is responsible for it. A. PA impl except TR069ParameterValue is responsible for it. B. TR069ParameterValue is responsible for it.

I understand. But isn't this implied if we say both of:

  1. Values can be anything that is valid for corresponding SOAP type, and
  2. PA has to handle whitespace collapsing?

...because SOAP will provide a value in the lexical representation, the PA will have handled the whitespace, so the value received by getDmtData() etc will be in the lexical representation (with collapsed whitespace).

I guess I was thinking that maybe we can get the meaning across without having to mention lexical and canonical representation, which are quite detailed XML concepts.

But I don't object to making it all more explicit.

For handling SetParameterValues RPC, the protocol adapter will extract parameter values from it.

  • These values can be anything that is valid for the corresponding SOAP data type.
  • The data type can be inferred from the XML itself via the xsi:type attribute.

Should this be "end of bullet"? So a total of four bullets?

TR069ParameterValue#getDmtData() and getDmtDataForList() are responsible for handling the value in lexical representation as defined by XML Schema[9]. Therefore, the protocol adapter does not need to translate the value from lexical representation to canonical representation, before passing the value to the TR069ParameterValue#getDmtData() or getDmtDataForList().

  • TR069ParameterValue#getDmtData() and getDmtDataForList() are not responsible for collapsing whitespace for all non-string data types, as defined by XML Schema [9].. Therefore, the protocol adapter needs to do it, before passing the value to the TR069ParameterValue#getDmtData() or getDmtDataForList().

That's OK ... but I find it harder to understand than my version! I think it's unfortunate that we require the reader to understand about lexical and canonical representation, and that whitespace is handled separately (a point that I just had to check in XML schema part 2). What do you think?

For handling GetParameterValues RPC, the protocol adapter must return GetParameterValuesResponse whose values are valid for the corresponding SOAP type. Note that this means that hexBinary and numeric values cannot contain embedded spaces.

I will apply it.

Note that on the GPV side we have avoided mentioning lexical and canonical representation.

bjhargrave commented 13 years ago

Comment author: Ikuo Yamasaki <yamasaki.ikuo@lab.ntt.co.jp>

Based on the comment from William, I had updated RFC149(ver 1.11.0).

After other REG members (Especially 2Wire) reviewed and confirmed, I'll close the bug.

bjhargrave commented 13 years ago

Comment author: Ikuo Yamasaki <yamasaki.ikuo@lab.ntt.co.jp>

REG agree to close this bug in Berlin F2F, Feb 14th 2011.