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

 


Help: OASIS Mailing Lists Help | MarkMail Help

uoml-x message

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


Subject: Re: [uoml-x] Using SVG in UOML


If we have a good resolution to evolve the specification, I agree to include a subset of SVG now.

Instead of GET_PAGE_SVG, we'd better to use a more general name as alternation of GET_PAGE_BMP, and specify the format as SVG.

-Alex

2011/4/18 Peter Junge <peter.junge@gmx.org>
Am 17.04.2011 02:15, schrieb Alex Wang:

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.

As UOML is an evolving standard, that will certainly have a couple of future versions, the inclusion of SVG will happen sooner or later anyway, hence the question is when to go ahead. My answer would be now.



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.

IMHO "GET_PAGE_BMP" should be changed into something more significant or adding a similar instruction for SVG: "GET_PAGE_SVG"



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?

That's why I was proposing to start with an UOML-internal SVG namespace and schema in oder to redefining "legacy" UOML Graphics Objects in an SVG-compatible way.

OpenDocument format has such a namespace (urn:oasis:names:tc:opendocument:xmlns:svg-compatible:1.0), see http://docs.oasis-open.org/office/v1.2/csprd03/OpenDocument-v1.2-csprd03.odt, page 86.


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.

Not necessarily with an the above approach I think. If my idea does not work, we would still be able to use the results of an according investigation for an informative Annex of mapping UOML Graphics Objects to its SVG equivalents.

Best regards,
Peter


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


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


       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





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