OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

plcs-dex message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: SV: [plcs-dex] Issue: Use of /IGNORE


All,

I meant to separate the behavior expected of a post-processor (i.e. importer
or translater) that knew about PLCS and DEXs and where/how data was
represented from the behavior of a general purpose EXPRESS parser.

The translator, because it knows that Identification_assignment is always
used in DEXs, would never even look at Product.Id.

Since that's the case, what value is assigned to Product.Id is not really
important so why not do the simplest thing you can.

Hope that makes sense,
David


>
> Hmm, David, you are saying that the static list of "do-not-use"
> attributes can be hardcoded into a parser so the value is never read at
> all, so the value "I am nothing", would never be seen.
>
> So, I agree with you: to what purpose are we cluttering up the exchange
> files with semantically null values that take up 7 bytes per attribute?
>
> The only thing I can think of is something like:
>
> "A conforming PLCS (DEX?) processor is required to ignore all
attributes
> listed in XXX when reading an exchange file. However, a validating
> processor may (must?) check that the attributes have a consistent value
> of '/IGNORE', otherwise an error (warning?) message is logged.
> Furthermore, upon creating a conforming excahange file, all attributes
> listed in XXX must be assigned the value '/IGNORE'."
>
> Regards,
> Per-Åke
>
> David Price wrote:
> > All,
> >
> > If the DEX specifies that any particular value shall always be
exchanged
> > using something like Identification_assignment rather than the Id
attribute,
> > then it cannot matter whether '/IGNORE', '' or 'Je suis null' is set
as the
> > Id attribute value or not. A conforming post-processor will never
look at
> > that value.
> >
> > A simple EXPRESS parser would tell you a mandatory attribute is
missing if
> > nothing were there if it was used to validate the data. Spelling out
/IGNORE
> > for an EXPRESS parser isn't useful - it doesn't understand English.
You
> > might as well reduce the file size by simply using ''.
> >
> > Cheers,
> > David
> >
> >
> >
> > --------- Original Message --------
> > From: Gyllström Leif <leif.gyllstrom@aerotechtelub.se>
> > To: Per-Åke Ling <per-ake.ling@eurostep.com>,
plcs-dex@lists.oasis-open.org
> > <plcs-dex@lists.oasis-open.org>
> > Subject: SV: [plcs-dex] Issue: Use of /IGNORE
> > Date: 23/09/05 10:28
> >
> >
> >>Yes
> >>
> >>See comment below
> >>
> >>Leif
> >>
> >>
> >>-----Ursprungligt meddelande-----
> >>Från: Per-Åke Ling [mailto:per-ake.ling@eurostep.com]
> >>Skickat: den 23 september 2005 11:12
> >>Till: peter.bergstrom@eurostep.com
> >>Kopia: rob.bodington@eurostep.com; plcs-dex@lists.oasis-open.org
> >>Ämne: Re: [plcs-dex] Issue: Use of /IGNORE
> >>
> >>
> >>To paraphrase: '/IGNORE' means the attribute should not have been
in the
> >
> > model at all in the first place, irrespective of whether I have a
value
> >
> >>for it or no, or even understand the semantics?
> >>
> >>In other words, walkig through the model we could statically
define the
> >>attributes that will always carry the value '/IGNORE' in every
exchange,
> >
> > and no other attributes will ever have the value '/IGNORE'? (Except
as a
> > true data value...)
> >
> >><LEIF> Yes ! There is a first draft uploaded to
dexlib/docs which
> >>shows a suggested "static" usage/non-usage of
all entity
> >
> > attributes.</LEIF>
> >
> >>
> >>Is this correct?
> >>
> >>Regards,
> >>Per-ÅKe Ling
> >>
> >>Peter Bergstrom wrote:
> >>> Do I understand correctly if this means the following:
> >>>
> >>> The description attribute on Product is optional. If
descriptions are
> >>> going to be assigned to entities instead of using the
attribute
> >
> > value, > mainly due to multilingual issues, it then means that
all
> >
> >>> Product.descriptions must be set to '/GNORE' even though
they (as
> >>> defined now) could just be left out?
> >>>
> >>> I think this is polluting the physical files, but it is
also slightly
> >>> more consistent than the current rule, so I will accept
it although I
> >
> > do
> >
> >>> not really see a need to change the current rule.
> >>>
> >>> Peter Bergström
> >>>
> >>>
> >>>     -----Original Message-----
> >>>     *From:* Rob Bodington
[mailto:rob.bodington@eurostep.com]
> >>>     *Sent:* den 23 september 2005 09:57
> >>>     *To:* plcs-dex@lists.oasis-open.org
> >>>     *Subject:* [plcs-dex] Issue: Use of /IGNORE
> >>>
> >>>     Hi
> >>>
> >>>     A core of plcs modellers met this week.
> >>>
> >>>     We raised and addressed this issue.
> >>>
> >>>     If anyone does not like the resolution please say so.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>     */Issue: RBN-1 by Rob Bodington (/**/05-09-02/**/)/*/
> >>>     minor_technical issue /
> >>>     /Resolution: Accept. Status: open/
> >>>
> >>>     /IGNORE is used inconsistently throughout the
capabilities.
> >>>
> >>>     According to AP239 annex and
> >
> > dexlib/help/dex/implementor_trans.xml,
> >
> >>>     the following should be used.
> >>>
> >>>     In particular optional values should default to '$'
and only be
> >
> > set
> >
> >>>     to '/IGNORE' if there is a value assigned.
> >>>
> >>>     *Value*
> >>>
> >>>
> >>>
> >>>     *Description*
> >>>
> >>>     ''
> >>>
> >>>
> >>>
> >>>     indicates user data managed by the sending system but
not
> >
> > provided
> >
> >>>     for data exchange.
> >>>
> >>>     '/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.
> >>>
> >>>     '/IGNORE'
> >>>
> >>>
> >>>
> >>>     Attribute values are set to '/IGNORE' when the
information that
> >>>     could be held by the attribute is instead assigned to
the
> >
> > instance
> >
> >>>     of the entity.
> >>>
> >>>     *Table — Attribute values*
> >>>
> >>>     *Comment: *(Rob Bodington 05-09-21*)*
> >>>     The proposal is that wherever an attribute should not
be used,
> >
> > i.e.
> >
> >>>     it should have been removed from the model as
assignment is used
> >>>     instead, it should be populated with /IGNORE,
regardless of
> >
> > whether
> >
> >>>     the attribute is used or not. This means that any
translator does
> >>>     not have to parse the attributes to determine whether
there is an
> >>>     assignment holding the value or not. This should be
consistent
> >>>     through out.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>     Regards
> >>>     Rob
> >>>
> >>>     -------------------------------------------
> >>>     Rob Bodington
> >>>     Eurostep Limited
> >>>     Web Page: http://www.eurostep.com
> >
> > <http://www.eurostep.com/>
> >
> >>>     http://www.share-a-space.com
> >
> > <http://www.share-a-space.com/>
> >
> >>>     Email: Rob.Bodington@eurostep.com
> >>>     Phone: +44 (0)1454 270030
> >>>     Mobile: +44 (0)7796 176 401
> >>>
> >>>
> >>>
> >>
> >>
> >>--
> >>==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                                        ^ ^
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> > ________________________________________________
> > Message sent using UebiMiau 2.7.2
> >
>
>
> --
> ========================================================
> 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                                        ^ ^
>
>
>
>
>
>

________________________________________________
Message sent using UebiMiau 2.7.2



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]