RE: [ubl-ndrsc] Comments to Tag Structure: Special Case of MarkupStructure

["Stuhec, Gunther" <gunther.stuhec@sap.com>]

Hello Bill,

I'am apologize that I was to fast with my comments of requirements. After a
further discussion with the developers I've seen that the additional
information "method" and "direction" are necessary for the interface of our
system only. They mustn't represents in the markup of the business document
(payload). 

Please take no notice of my comments, because the interface can regonize and
add this information themselve.

Regards,
	Gunther

-----Original Message-----
From: Burcham, Bill [mailto:Bill_Burcham@stercomm.com]
Sent: Donnerstag, 29. November 2001 13:13
To: Stuhec, Gunther; ubl-ndrsc@lists.oasis-open.org
Subject: RE: [ubl-ndrsc] Comments to Tag Structure: Special Case of
Markup Structure


> -----Original Message-----
> From: Stuhec, Gunther [mailto:gunther.stuhec@sap.com]
> Sent: Thursday, November 29, 2001 3:46 AM
> To: ubl-ndrsc@lists.oasis-open.org
> Subject: [ubl-ndrsc] Comments to Tag Structure: Special Case of Markup
> Structure
> 
> 
> Hello,
> Mark describes in his document "Position Paper: Tag 
> Structure" under chapter
> 3.1.1 (Markup Structure) that are underscores ( _ ), periods ( . ) and
> dashes ( - ) MUST NOT be used. 
> This is the point. For the efficient development of 
> interfaces and defining
> methods it will be helpful to using this separators for 
> building markups.

Sounds like you are talking about encoding object invocations here Gunther.
Is that in-scope for UBL?  I haven't heard any discussion of that model.  Is
there even a concept of objects and methods and invocations and in and out
parameters in UBL?

> The markup should expanded and distinguishes between three 
> elementary parts:
> object, methods and directions by using any separation. 
> The "object" denotes the entity which makes a method available (i.e.
> PurchaseOrder). It includes the object class, property term and
> representation term according the semantic guidelines in 
> chapter 3.12. The
> object is represented in UCC without any separators. 
> The "method" represents the type of operation (i.e. "Create", 
> "Delete",
> "Modify").
> And the "direction" denotes whether a component implements 
> the interface as
> a service (direction = In) or the component uses the 
> interface for a call
> (direction = "In" or "Out").

Do you mean that "In" is used to denote the input to a service, and "Out" is
used to denote the result of a service invocation?

> A preferred sign for the separation is the underscore ( _ ).
> The markup structure would like to be then:
> 	<object>_<method>_<direction>
> 	Example: PurchaseOrder_Create_In
> Within each part of the interface - object, method and 
> direction - we use
> the UCC (Upper Camel case) convention. The three parts are 
> separated via an
> underscore '_' for the following reasons:
> 	1.	In the development phase the software developer 
> must define
> the object and the method which is made available via the object. 
> 	2.	Any confusion concerning the object part or the 
> method part
> within an interface has to be avoided. I.e. using no separators in
> 'OrderItemDeleteIn' the object could be Order (method = 
> ItemDelete) or the
> object could be OrderItem (method = Delete).
> 	3.	Using the underscore results in no technical 
> restrictions
> concerning the proxy generation (for example in Java).
> 	4.	It is possible to implement check tools which 
> check that two
> underscores are used.
> 	5.	Reading an interface it is more easy to 
> distinguish between
> the three parts if there are separated using separators like '_'.

Even though I think this proposal is out of our scope, I'll argue further
that there is still no need for this sort of element "name mangling" in XML.
There's plenty of structure already available.  What's wrong with plain old:

<PurchaseOrder>
 <Create sense="In">
 ...
 </Create>
</PurchaseOrder>

This addresses 2, 3, 4 (schema validation), 5.  I don't think reason 1 is an
issue.  

> 
> Regards,
> 	Gunther
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>