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


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]