Part 2 rewrite for part names and part references

[MURATA Makoto]

Folks,

Having moved Annex A to the body, I had a chance to
study OPC part names and OPC part references
together.

I find a serious problem.  The definition of OPC part
names  and the resolution of OPC part references
are in conflict.  OPC part names can have non-ASCII
while OPC part references are resolved to
ASCII.  This problems was introduced in the BRM,
since we updated the definition of OPC part names
without updating the resolution procedure of OPC
part references.  Both the currently published
standard and my rewrite have this problem.

Regards,
Makoto




2014-02-04 MURATA Makoto <eb2m-mrt at asahi-net.or.jp>:

> As the owner of the below DRs, I tried to provide a solution.   See
> the attached document.  It implements changes sketched in
> WG 4 N 0207.
>
> 09-0280 - general DR about sections of OPC assuming non-ASCII is disallowed
> 09-0281 - terminology; all uses of "part" should specify what kind of part
> is meant
> 09-0283 - similar to 09-0280
> 09-0284 - terminology; need to re-associate the ABNF term names with the
> prose for part names
> 09-0285 - terminology; use of "part IRI" and "part URI"
> 09-0286 - need to update 9.2 (Part Addressing) to specify the format of a
> reference, based on the changes to be made to 9.1.1 (Part Names)
> 09-0288 - same as 09-0286, but for 9.3.2 (Relationship Markup)
> 09-0291 - terminology; specify what "Unicode string" means, based on the
> changes to be made to 9.1.1
> 09-0292 - which characters are allowed in a part name (e.g., whitespace,
> delimiters, special characters)
> 13-0002 - fix previous changes made to Annex H for introduction of
> non-ASCII support
> 10-0015 - clarify "source part" for relationships
>
>
> Regards,
> Makoto
>



-- 

Praying for the victims of the Japan Tohoku earthquake

Makoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20140209/73754f73/attachment.html>