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


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] Re: 3 XML Design Principles [T2005013101A6]

[ Lists Home | Date Index | Thread Index ]

On January 31 2005 at 16:29:21 EST Bullard, Claude L (Len) <len.bullard@intergraph.com> wrote:
> Slightly orthogonal, yes, but to demonstrate that even the data head
> vs document head perspectives on XML leave out what can
> be done with XML, so one should be very wary of best
> practices without understanding the underlying model of
> the application.   VRML had a way of exposing my preconceived
> notions from SGML as the humbugs they were.  The X3D
> experience, even moreso, since in that, the assumptions
> of XML and XSD got pushed to the edge.  Real time object
> models are not really documents or data in the way many
> think about those things.  X3D is a modeling language
> and a real time animation rendering.  The advantages
> to that from XML are not *as* great as one suspects,
> and there are some penalties.  There are benefits,
> but again, not nearly as many as in transactions,
> serialized documents, data base export/imports, etc.
> In interchange applications, ummm... ok some but mainly
> the same:  no new parse, some validation, good db tools,
> quick and dirty editors (not really good ones either
> because modeling is interactive graphics modeling and
> the XML generic tree editors aren't the best approach).
> So XML for graphics is a good thing, but no magic and less juju.
> Tim Bray said it best when X3D was getting started:  get
> the object model right first.   The markup model is
> trivial after that.
> But tossing in the best practices without knowing the
> object model? That won't be trivial at all, and in fact,
> can lead to some really ugly designs.  Keep in mind
> WHY you use XML and optimize for that.
> len
> From: Jeff Rafter [mailto:lists@jeffrafter.com]
> > OTOH, since ROUTEs are from DEF names to DEF names, USEd
> > objects can get you in trouble.  If for example, you
> > send a transform to the rotation field, all of the
> > USE'd objects spin.
> In SVG this is roughly similar-- but in general because of the box model
> the rotations are cumulative-- so you can rotate a rotation without much
> penalty. Where things get sticky in SVG is calculating out the CSS
> inheritance and selectors. Applying textures maybe similar-- but
> multiply that against all of the possible CSS properties and you don't
> end up saving much time with regard to performance. To be fair to
> Roger's original post, this is a slightly orthogonal tangent... it is
> just a real world example where an id/idref mechanism isn't all it is
> cracked up to be. Or in Len's case, is a far better approach.
> Cheers,
> Jeff Rafter
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
> The list archives are at http://lists.xml.org/archives/xml-dev/
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://www.oasis-open.org/mlmanage/index.php>
> XM Satellite Radio Inc.
> http://www.xmradio.com
> This message contains information that may be confidential or privileged.
> The information is intended solely for the recipient and use by any other party is not authorized. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic transmission in error, please notify us immediately by telephone (202.380.4000), fax (202.380.4500) or by electronic mail (postmaster@xmradio.com)


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS