Thanks, Ryan, this was also discussed in the meeting..
The invisible update is just a special kind of update and the spec cannot prevent it as far as the private state machine in the subproperty allows for it.
The thing is, if you do not know how the private state machine behaves, you have to delete..
I hope this is clear and acceptable
Rgds
dF
Dr. David Filip
=======================
LRC | CNGL | LT-Web | CSIS
University of Limerick, Ireland
telephone: +353-6120-2781
cellphone: +353-86-0222-158
facsimile: +353-6120-2734
mailto:
On Fri, Aug 9, 2013 at 12:51 AM, Ryan King <> wrote:
David, the only contention I have with the PR is that I could potentially have the same subState value for different state values. In this particular case,
as long as I don’t have to actually “delete” and “reset” the same value in subState when state changes (e.g. it can be considered an “invisible update” as you pointed out on another thread) then I’m OK with it.
Ryan
From: [mailto:]
On Behalf Of Dr. David Filip
Sent: Tuesday, August 6, 2013 12:27 PM
To:
Subject: [xliff] Call for dissent on implementing the general properties sub-properties solution, re csprd 01 comments 021 and 053
Hi all,
As explained in today's meeting, for all property attributes in the spec that have a sub-property specified, such as fs and subFs, state and subState etc.
I have implemented a uniform provision consisting of a Contsraint and a PR
See it here e.g. for state and subState
Constraints
·
If the attribute subState is
used, the attribute state MUST be specified as well.
Processing Requirements
·
If the attribute state is updated,
the attribute subState MUST be updated or deleted.
Unless I hear otherwise by Thu, Aug 10, COB PDT, I will consider this our official resolution of the pertaining csprd01 comments.
Best regards
dF
Dr. David Filip
=======================
LRC | CNGL | LT-Web | CSIS
University of Limerick, Ireland
telephone: +353-6120-2781
cellphone: +353-86-0222-158
facsimile: +353-6120-2734
mailto:
