[OASIS Issue Tracker] Commented: (EMIX-352) Schema issues relatedto emix.xsd wd22

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ http://tools.oasis-open.org/issues/browse/EMIX-352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=25139#action_25139 ] 

Toby Considine commented on EMIX-352:
-------------------------------------

Comments from the Schema perspective:

Some issue apply to the specification as well as the schema. 

(1) product is an element (but ProductType is a type). ProductType is annotated as "EMIX Market Tender Product Type" which is overly restrictive. There's also a TEMIX product type; why both with similar annotations? 

Done

(2) DeliveryType - how does this differ from Transportation? the information model includes only injection. Where are the two end points? 

??? Delivery is the term we agreed for all metrology related issues. It has nothing to do with Transport.


(3) productDescription has measurement as the only attribute. The annotation should say "The respective product schemas extend this abstract class. See e.g. power-products.xsd" 

Done - but w/o referrence to other schemas which may change


(4) emix:duration has a run to - emix:DurationType which is xcal:duration and xcal:parameters. I think it's several layers to get to xsd:simplelType duration. Consider documenting this. 

OK

(5) ItemBaseType needs more explanation in the spec. 

?? ItemBaseType states "Abstract base class for units for EMIX Product delivery, measurement, and warrants. Item as in PO Item, Requisition Item, Invoice Item, Lading Item. Item does not include Quantity or Price, because a single product description or transaction may have multiple quantities or prices associated with a single item."


(6) QuantityType diagram in Spy isn't useful; the restriction is more clear (base="xs:float") 

Not sure what this means


(7) A description of the benefits and costs of the approach to units would be valuable in the spec. 

Not in Schena

(8) Why not the codes rather than strings in SiScaleType? I believe Anne Hendry raised an issue on that. I like having the selection from units and type subject to automatic validation via schemas. 

?? Is the a request for xstoken instead of xsstring? Not actionable


(9) The pattern for EmixExtensionType ("x-" prefix) should be explained in the spec with a reference to NIEM. 

In Appendix already

(10) product has an annotation ending with "...Usually used in tenders". But the product is key to any price information exchange; why is this limited? Moreover, the ProductType is distinct from the TemixType, so the transitive products would seem to be related to TemixType not ProductType. 

Eliminated verbiage

(11) How does element currency connect to the ISO currency codes? An annotation would be nice (8.2.3) 

OK

(12) The documentation/annotation for emixconstraints is lengthy compared to the other annotations nib e.g. product (see product.png) and not in the same style. Other elements should have brief documentation as should emixconstraints. 

Schema documentation is not driven by how it appears in an automatically derived graphic UML diagram in a proprietary tool

(13) Why is the type "emixconstraints" rather than emixConstraints? doesn't that violate the camelCaseRule? 

Where do you find this? the string emixconstraints appears neither in the schema or in the spec.



(14) Lines 266-280 are commented out. Why? Shouldn't be in Public Review if not used. 

As documented repeatedly, and communicated to the lsit repeatedly, we offered a version of EMIX.xsd with the GML comments out for those who wished to experiment with a smaller schema.



> Schema issues related to emix.xsd wd22
> --------------------------------------
>
>                 Key: EMIX-352
>                 URL: http://tools.oasis-open.org/issues/browse/EMIX-352
>             Project: OASIS Energy Market Information Exchange (eMIX) TC
>          Issue Type: Sub-task
>          Components: schema
>    Affects Versions: wd22
>         Environment: William Cox
>            Reporter: William Cox
>            Assignee: Toby Considine
>
> This is a list of questions and comments. Line numbers are as shown by XMLspy for emix.xsd.  The package of XML Spy diagrams has been uploaded to the archive under Contributions at http://www.oasis-open.org/committees/download.php/41712/SchemaWd22DiagramsEmixSchema.zip 
> Some issue apply to the specification as well as the schema.
> (1) product is an element (but ProductType is a type). ProductType is annotated as "EMIX Market Tender Product Type" which is overly restrictive. There's also a TEMIX product type; why both with similar annotations?
> (2) DeliveryType - how does this differ from Transportation? the information model includes only injection. Where are the two end points?
> (3) productDescription has measurement as the only attribute. The annotation should say "The respective product schemas extend this abstract class. See e.g. power-products.xsd"
> (4) emix:duration has a run to - emix:DurationType which is xcal:duration and xcal:parameters. I think it's several layers to get to xsd:simplelType duration. Consider documenting this.
> (5) ItemBaseType needs more explanation in the spec.
> (6) QuantityType diagram in Spy isn't useful; the restriction is more clear (base="xs:float")
> (7) A description of the benefits and costs of the approach to units would be valuable in the spec.
> (8) Why not the codes rather than strings in SiScaleType? I believe Anne Hendry raised an issue on that. I like having the selection from units and type subject to automatic validation via schemas.
> (9) The pattern for EmixExtensionType ("x-" prefix) should be explained in the spec with a reference to NIEM.
> (10) product has an annotation ending with "...Usually used in tenders". But the product is key to any price information exchange; why is this limited?  Moreover, the ProductType is distinct from the TemixType, so the transitive products would seem to be related to TemixType not ProductType.
> (11) How does element currency connect to the ISO currency codes? An annotation would be nice (8.2.3)
> (12) The documentation/annotation for emixconstraints is lengthy compared to the other annotations nib e.g. product (see product.png) and not in the same style. Other elements should have brief documentation as should emixconstraints.
> (13) Why is the type "emixconstraints" rather than emixConstraints? doesn't that violate the camelCaseRule?
> (14) Lines 266-280 are commented out. Why? Shouldn't be in Public Review if not used.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira