[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [uoml-x] IDL?
At risk, that I say something stupid, because I just started to learn about IDL. I find the idea of IDL functions calling XML instructions considerable. As far as I understand, that should satisfy BRM comments CZ-03, CZ-06 and JP-09. What I would do is defining interfaces for the UOML graphics objects similar to how SVG does it. Please refer: http://www.w3.org/TR/SVG/shapes.html#DOMInterfaces As well, defining UOML command objects as IDL functions. Best regards, Peter Am 21.04.2011 03:32, schrieb Alex Wang: > It is a IDL proposal(written in Chinese) which works together with XML > instruction. It is the mechanism that application software call IDL > function, then IDL function call DCMS via XML instruction. Shall we keep > this mechanism or let IDL one be alternate option of XML interface? or > other idea? > > -Alex > > 在 2011年4月18日 下午7:52，刘宁胜 <lns@sursen.com > <mailto:lns@sursen.com>>写道： > > We already have a IDL part in UOML's chinese version,see attached > document. > > > 2011/4/19 Alex Wang <alexwang@sursen.com <mailto:alexwang@sursen.com>> > > Before we decide if they shall become normative or informative, > we need figure out the relationship of IDL functions and XML > instructions. > > I have asked OASIS whether a non-XML standard is acceptable for > OASIS, the answer is yes. > > -Alex > > > 2011/4/18 Peter Junge <peter.junge@gmx.org > <mailto:peter.junge@gmx.org>> > > I think these are questions, that engineers who implement > UOML should answer. > > In case we're adding IDLs, another question would be if they > shall become normative or informative, e.g. in an Annex. > > Peter > > Am 17.04.2011 07:16, schrieb Alex Wang: > > Another issue we need discuss is IDL. IDL has higher > efficient than than > XML, do we need to add IDL as an alternate choice of > instruction form? > Or we insist on XML only to wait the enhancement upgrade > of XML parser? > > -Alex > > 2011/4/16 Alex Wang <alexwang@sursen.com > <mailto:alexwang@sursen.com> <mailto:alexwang@sursen.com > <mailto:alexwang@sursen.com>>> > > > SVG is an important issue. When UOML is designed in > 2005, SVG is too > complicated and not popular, doesn't meet the principle > of UOML "as > simple as possible". But in 2011, SVG has become a part > of HTML5, > almost all of browser support SVG, it seems that SVG > will be more > popular than PDF in future. > > I suggest that we can use SVG as an optional format for > get page > bitmap, although SVG is not a bitmap format. Thus the > user of UOML > can easily display/print the page by simply send it to > browser. > > Regarding using SVG to describe UOML graphics object, > there are some > problems: > 1. Compatibility requirement. If we change to SVG > description in new > version, how to keep compatibility of old version standard? > 2. SVG is a non-status page description language, while > UOML adopts > graphics status to follow PDF. Although it is > convertible, but the > graphics model of UOML will be changed significantly, the > compatibility will be much harder. > > It is possible to have more problems, what is your opinion? > > I'd like to use existing standard as possible, but we > must resolve > above problems before we go. > > -Alex > > 2011/4/15 Peter Junge <peter.junge@gmx.org > <mailto:peter.junge@gmx.org> <mailto:peter.junge@gmx.org > <mailto:peter.junge@gmx.org>>> > > > Hi everyone, > > please comment the document I have just uploaded. It's > the first > working draft of UOML carrying version number 1.1. > > I'm still not 100% sure which direction to go with regard to > UOML Graphics Objects/SVG. > Mapping the Graphics Objects to SVG would be expressing > the same > thing in two different ways. From my point of view it > might be a > smarter approach to rebuild the UOML Graphics Objects with a > subset of SVG. OpenDocument Format does it that way. ODF > defines > an internal svg: namespace with reusing SVG elements and > attributes and trimming them down to the functionality they > need. Would it be possible to redefine the Graphics > Objects in > an identical way with a UOML-internal subset of SVG? > > Best regards, > Peter > > > Am 15.04.2011 21:02, schrieb peter.junge@gmx.org > <mailto:peter.junge@gmx.org> > <mailto:peter.junge@gmx.org <mailto:peter.junge@gmx.org>>: > > > This is the first working draft of UOML with version > number 1.1 > > Most significant changes, considerables: > By Kaihong > ------------ > - 3.4 GET: Significantly extended, more examples > - New Clause 4.3.1: DRAWPARA with many dependend small > changes (I added > quite a few comments) > - Annex A,C: New schemas > > By Peter > -------- > - 1.1 Terminology: Rephrased the definitions for docbase and > docset in a > way that I find clearer. (Comments welcome) > - New Clause 1.7: Added draft of simple use case. It can > certainly be > elaborated > - 2.2 Change the ambigous sentence about the root docset > into a > definition. > - New Clause 2.3.1: Root Docset as special case of Docset > - 4.11.1,2: ARC and Bezier are IMHO redundant to SUBPATH > - 4.11.5 Image: Proposing change of schema and semantics > - 4.11.7,8: RECT and ROUNDRECT can IMHO be merged as in SVG > > > -- Mr. Peter Junge > > The document named UOML (Unstructured Operation Markup > Language) Part 1 1.1 > WD01 REV 01 (UOML-X-Part1v1.1-wd01-rev01.doc) has been > submitted by Mr. > Peter Junge to the OASIS Unstructured Operation Markup > Language eXtended > (UOML-X) TC document repository. > > Document Description: > This is the first working draft of UOML with version > number 1.1 > > View Document Details: > http://www.oasis-open.org/committees/document.php?document_id=41847 > > Download Document: > http://www.oasis-open.org/committees/download.php/41847/UOML-X-Part1v1.1-wd01-rev01.doc > > > PLEASE NOTE: If the above links do not work for you, your > email application > may be breaking the link into two pieces. You may be able > to copy and paste > the entire link address into the address field of your web > browser. > > -OASIS Open Administration > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the > OASIS TC that > generates this mail. Follow this link to all your TCs in > OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS > TC that > generates this mail. Follow this link to all your TCs in > OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]