[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [plcs-dex] Implementer guidance (Attribute values section restored)
Thanks - I have corrected some of the links in main_toc.xml as well
e.g. implementor_model.xml to impl_model.xml
Regards
Rob
-------------------------------------------
Rob Bodington
Eurostep Limited
Web Page: http://www.eurostep.com http://www.share-a-space.com
Email: Rob.Bodington@eurostep.com
Phone: +44 (0)1452 810 960
Mobile: +44 (0)7796 176 401
-----Original Message-----
From: mats.nilsson@fmv.se [mailto:mats.nilsson@fmv.se]
Sent: 07 February 2006 07:48
To: rob.bodington@eurostep.com
Cc: plcs-dex@lists.oasis-open.org
Subject: SV: [plcs-dex] Implementer guidance (Attribute values section
restored)
The section is back! (do a CVS update)
(Info -> Implementors Information -> Setting attribute values)
I need help with updating the text to reflect the recent discussion though.
Regards,
Mats
P.S:
I had an archived version of DEXlib where I found the 'setting attribute
values' section.
I hope I havn't edited away any other sections...
If so, tell me and also they shall arise again! ;o)
-----Ursprungligt meddelande-----
Från: Rob Bodington [mailto:rob.bodington@eurostep.com]
Skickat: den 7 februari 2006 08:07
Till: Nilsson, Mats maxnn
Ämne: RE: [plcs-dex] Implementer guidance
That's the one - it seems to have vanished
Regards
Rob
-------------------------------------------
Rob Bodington
Eurostep Limited
Web Page: http://www.eurostep.com http://www.share-a-space.com
Email: Rob.Bodington@eurostep.com
Phone: +44 (0)1452 810 960
Mobile: +44 (0)7796 176 401
-----Original Message-----
From: mats.nilsson@fmv.se [mailto:mats.nilsson@fmv.se]
Sent: 07 February 2006 06:29
To: rob.bodington@eurostep.com
Subject: SV: [plcs-dex] Implementer guidance
I think I know what section you mean... a four-line table that explanins
"/IGNORE", "' '", "$" and "NULL", right?!
I'll look in to it right away and see if I can find and restore it...
Regards,
Mats
-----Ursprungligt meddelande-----
Från: Rob Bodington [mailto:rob.bodington@eurostep.com]
Skickat: den 6 februari 2006 21:38
Till: 'Barker, Sean (UK)'; plcs-dex@lists.oasis-open.org
Kopia: mike.ward@eurostep.com; 'David Price'; 'Tim Turner'; 'Per-Åke Ling'
Ämne: RE: [plcs-dex] Implementer guidance
Was there any conclusion on this?
The bit in the help section of DEXlib seems to have been deleted (well I
could not find it)
Regards
Rob
-------------------------------------------
Rob Bodington
Eurostep Limited
Web Page: http://www.eurostep.com http://www.share-a-space.com
Email: Rob.Bodington@eurostep.com
Phone: +44 (0)1452 810 960
Mobile: +44 (0)7796 176 401
-----Original Message-----
From: Barker, Sean (UK) [mailto:sean.barker@baesystems.com]
Sent: 24 January 2006 17:43
To: plcs-dex@lists.oasis-open.org
Cc: mike.ward@eurostep.com; David Price; Tim Turner; Per-Åke Ling
Subject: RE: [plcs-dex] Implementer guidance
Following this correspondence, I suspect that the problem arises because
"/IGNORE" is being used to mean two separate but related things. Firstly, it
is being used as an instruction TO implementers on HOW TO populate the data
model. Secondly, it being used BY implementers on how the model HAS BEEN
populated.
As I understand the part 21 file, each entity is specified by a list of
parameters, and that therefore, when the file is parsed, the correspondence
of a token to a parameter is deduced by the order of the tokens. The
implication is that, if a token is missed out, the following token is then
mistakenly read as the value of the corresponding parameter. The function of
the $ is then as the token used to ensure that an unused optional parameter
does not desynchronize the actual data with the parameter list. If an
implementation method works by name/value pairs (e.g. identifier="A123"),
then the use of $ is not required.
In the case of required attributes, we have four possibilities:
"X123" - the attribute has an actual value
"" - the attribute has an empty value
"/NULL" - the system does not have a value for the attribute
"/IGNORE" - the attribute value is found in an assigned attribute
As an instruction TO implementers in a DEX "/NULL" and "" should never occur
("" should not occur as we are trying to illustrate how to use the data
model). Further, in the case of "/IGNORE" there should be an obligation to
identify the assigned attribute, that is, the type of attribute assigned and
the role given to that attribute.
Either 1) when decoding the contents of an attribute, "" and "/NULL" may
only occur in place of an actual value, such as "X123". If the attribute was
specified as "/IGNORE", then the value of the contents should be "/IGNORE",
even if the assigned attribute has the value "" or "/NULL".
Or 2) when decoding the contents of an attribute, "" and "/NULL" may occur
in place of an actual value, such as "X123". If the attribute was specified
as "/IGNORE", then the values "" and "/NULL" indicate not only the value of
the attribute, but also the fact that the assignment has been omitted.
The receiving system must always know about the "/IGNORE" in the
specification, since it needs to know to look for the assigned attribute.
Case 2 adds an additional complication, that it must not look for an
assigned attribute if the "/IGNORE" is omitted.
Rejecting option 2 seems to make the processing simpler. Indeed, since it
already does not need to check the attribute value, and that an actual value
would be an error, we could omit the "/IGNORE" and send "". This would also
serve the case for non-string attributes, since it does not require a flag
value equivalent to "/IGNORE". It also means that we can record the
historical development of data, which may have an attribute set to "/NULL"
initially, but later set to "X123" - a situation more likely to occur in a
distributed environment.
In the case of an optional attribute, we can use the same logic, but
a) "/NULL" will never occur.
b) It would make sense to distinguish between blank ("") and omitted
($), however we then need a new lexical convention, such as "$" or "$$"
(using $ to represent dollar), which might have further ramifications on
other STEP conventions.
I therefore propose to split the advice into two sections:
1) The specification of the content of an attribute is either a
value, or "/IGNORE" (or // /IGNORE for a non-string).
2
a) The decoding of an attribute is configured by the
specification of a value or "/IGNORE"
b) The decoding of an attribute specified by a value must
also deal with the cases "" and "/NULL"
c) The value of attribute specified as "/IGNORE" will be
ignored. String attributes should not be set to any value other than "" or
"/IGNORE".
Discussion of $ will be omitted, as OASIS deals with XML files.
For an omitted optional attribute, I assume the part 28 binding handles this
case.
Comments, questions, purple ink from disgusted of Tunbridge Wells, etc.
Sean Barker
0117 302 8184
-----Original Message-----
From: Per-Åke Ling [mailto:per-ake.ling@eurostep.com]
Sent: 16 January 2006 18:19
To: Tim Turner
Cc: 'mike.ward@eurostep.com'; 'David Price'; plcs-dex@lists.oasis-open.org
Subject: Re: [plcs-dex] Implementer guidance
*** WARNING ***
This mail has originated outside your organization, either from an external
partner or the Global Internet.
Keep this in mind if you answer this message.
Although I tend to sympathize with Dave since I am doing practical
implementations I find the whole issue confusing.
If, in an actual implementation, we are to ignore all attributes except the
ones that actually are to carry data (such as the id in
Identification_assignment), then it is rather pointless to specify /IGNORE
or whatever else. In effect, what the capability ends up saying is that
"these few attributes carry real data, do what you please with the rest but
under no circumstances should they be read".
I can acept that argument, but it certainly goes against the current way the
attributes are specified. My understanding is that currently a conforming
implementation _must_ specify /IGNORE et al in the unused attributes.
Otherwise we can simply state "fill in any random junk in the mandatory
attributes, and leave the optional ones unset (if not, ignore them anyway
when reading the file)".
Regards,
Per-Åke
Tim Turner wrote:
>
> I have several thoughts about this.
>
> Dave has a point, although (at the risk of being contentious) if we
> are to enforce this, should there not be Rules in each DEX's EXPRESS
> schema to state that the relevant (entities') attribute value shall be
"/IGNORE"?
>
> With respect to the earlier question, I have pasted the usage guidance
> from PDM schema below.
> Quote:
> "* Empty string '' indicates user data managed by the sending system
> but not provided for data exchange.
> * String '/NULL' indicates user data in a mandatory attribute that is
> not managed by the sending system or currently not known.
>
> * $ is used in the physical file, if an optional attribute is not
> instantiated."
> End Quote.
>
>
> Adapting this I think that:-
>
> "/IGNORE" should be used where an optional attribute is instantiated
> as reference data and reference data has been provided;
>
> "" the empty string, could be used where an optional attribute would
> be instantiated as reference data, but none is provided (i.e. I have
> it but will not provide it at present);
>
> "/NULL" could be used where an optional attribute would normally be
> instantiated without reference data, but the value is either not
> managed by the sending system or not currently known.
>
> Else, "$" could be used in a P21 file where an optional attribute is
> not instantiated reference data and is not available in the reference
> data;
>
> Regards,
> Tim
> NB - all these situation revolve around the attributes of the ARM
> entity. What about the case where there is NO attribute present in the
> EXPRESS arm, but reference data is needed?
>
>
>
>
> -----Original Message-----
> From: Mike Ward [mailto:mike.ward@eurostep.com]
> Sent: 16 January 2006 07:51
> To: 'David Price'; plcs-dex@lists.oasis-open.org
> Subject: RE: [plcs-dex] Implementer guidance
>
> I tend to agree with Dave here.
>
> Another (albeit minor) consideration is that P28 data files can simply
> miss out the elements corresponding to OPT attributes and the
> distinction between /IGNORE and $ provides a handy way of reconciling
> p21 and p28 files.
>
> Mike
>
> --
>
> Dr Mike Ward
> Eurostep Limited
> 7 Dean Lane Head
> Old Allen Road
> Bradford
> BD13 3RT
> UK
> tel: +44 1274 831187
> fax: +44 1274 831187
> mob: +44 7909 915976
> email: mailto:mike.ward@eurostep.com
> url: www.eurostep.com
>
> Eurostep: open solutions, organization, and people.
>
>
> All,
>
> Specifying /IGNORE is not useful to a post-processor at all as the
> attribute value will never be read. Any DEX-based post-processor
> reading the file will know to use Reference Data, not the explicit
attribute.
> So, you should simply leave it as $ as that takes less space and does
> not require the pre-processor to set a value for every attribute
> replaced by the use of Reference Data which can add noticable costs
> for very large datasets.
>
> Cheers,
> David
>
> --------- Original Message --------
> From: nigel.shaw@eurostep.com
> To: plcs-dex@lists.oasis-open.org <plcs-dex@lists.oasis-open.org>
> Subject: RE: [plcs-dex] Implementer guidance
> Date: 16/01/06 09:07
>
> >
> > There are multiple possible interpretation of "$" whilst
> > /IGNORE has a > defined meaning. Therefore send "/IGNORE"
> would be my preference.
> >
> > As examples, "$" can be interpreted as "there is no
> value", "I do not know > the value", "I know the
> value but do not want to tell > you", "you are not >
> allowed to know the value",...
> >
> > Nigel
> >
> >
> >
> > -----Original Message-----
> > From: Barker, Sean (UK) [mailto:sean.barker@baesystems.com]
> > Sent: 16 January 2006 08:47
> > To: plcs-dex@lists.oasis-open.org
> > Subject: [plcs-dex] Implementer guidance > > > > I am resolving
> an issue on the implementer guidance for /IGNORE.
> >
> > Attribute values are set to '/IGNORE' when the information that
> could > be held by the attribute will be instead assigned to the
> instance of > the entity. Note: required attributes will always have
> an equivalent > assigned, whereas optional attributes need not be
assigned.
> >
> > While this describes how to populate instance diagrams, the
> question arises, > what happens in the physical file. That is, should
> an unpopulated > optional attribute contain the value "$"
> or > "/IGNORE"?
> >
> >
> > Sean Barker
> > 0117 302 8184
> >
> >
> >
> ********************************************************************
> > This email and any attachments are confidential to the intended >
> recipient and may also be privileged. If you are not the intended >
> recipient please delete it from your system and notify the sender. You
> > should not copy it or > use it for any purpose nor disclose or
> distribute its contents to any other > person.
> >
> ********************************************************************
> >
> >
> >
> >
> >
> >
>
> ________________________________________________
> Message sent using UebiMiau 2.7.2
>
>
>
>
> *DISCLAIMER: ***SECURITY LABEL: NOT PROTECTIVELY MARKED*** The
> information in this message is confidential and may be legally
> privileged. It is intended solely for the addressee. Access to this
> message by anyone else is unauthorised. If you are not the intended
> recipient, any disclosure, copying, or distribution of the message, or
> any action or omission taken by you in reliance on it, is prohibited
> and may be unlawful. Please immediately contact the sender if you
> have received this message in error. This e-mail originates from LSC
Group.
> Registered in England & Wales No 2275471 Registered Office: Devonport
> Royal Dockyard, Devonport, Plymouth, PL1 4SG *
>
>
--
========================================================
Per-Åke Ling email: per-ake.ling_AT_eurostep.com .~.
Eurostep AB mobile: +46 709 566 490 / v \
Vasagatan 38 http://www.eurostep.com /( _ )\
SE-111 20 Stockholm ^ ^
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]