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


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-ndrsc message

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

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

> -----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:

 <Create sense="In">

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

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

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

Powered by eList eXpress LLC