Re: DTDs for VRML

Clay Graham (cyber23@best.com)
Tue, 15 Dec 1998 19:44:31 -0800

Just to follow up.

Not "everyone" is saying the XML approach should look like VRML97. I know people have been talking about alternitives.

Sorry.

Just making a point.

Clay

-----Original Message-----
From: Clay Graham [SMTP:cyber23@best.com]
Sent: Tuesday, December 15, 1998 6:20 PM
To: 'Bullard, Claude L (Len)'; Daniel Lipkin; enterprise@vrml.org
Subject: RE: DTDs for VRML

EWG,

I know everyone is busy making VRML97 into xml but I think is the wrong
approach.

I think we should think more about objects and interfaces than shapes and
geometries.

For example:

<BOX>
<TRANSFORM>
</TRANSFORM>
<CONE>
</CONE>
</BOX>
<CONE>
<TRANSFORM>
</TRANSFORM>
<COLOR>
</COLOR>
</CONE>

instead of....

<TRANSFORM>
<SHAPE>
<GEOMETRY>
<BOX>
</BOX>
</GEOMETRY>
</SHAPE>
<CHILDREN>
<TRANSFORM>
<SHAPE>
<GEOMETRY>
<CONE>
</CONE>
</GEOMETRY>
</SHAPE>
</CHILDREN>
</TRANSFORM>
<TRANSFORM name="Cone_XFORM">
<SHAPE>
<GEOMETRY>
<CONE>
</CONE>
</GEOMETRY>
</SHAPE>
</TRANSFORM>

The issue seems to me primarily is the mapping to the scripting object and
the DOM (as well as the way the xml looks), because with my approach you
can do something like:

(pseudo code)
//move all objects in scene 10 x and change them to red
for each object in document.elements("scene").objects

//instantiate a "true" 3d object
3DObject obj = new 3DObject();

//cast the unkown object
set obj = element;

//make an interface to color and transform
ITransform xform = ITransform();
IColor color = IColor();

//get the interfaces to the object
xform = obj;
color = obj;

//make a color and a vector
Color colorVec = new Color();
Vec3f xformVec = new Vec3f();

colorVec.SetColor(1, 0, 0);
color.DiffuseColor = colorVec;

xformVec = xform.Translation;
xformVec.X = xformVec.X + 10;

next object

get it?

Clay

-----Original Message-----
From: Bullard, Claude L (Len) [SMTP:clbullar@ingr.com]
Sent: Tuesday, December 15, 1998 1:44 PM
To: Daniel Lipkin; enterprise@vrml.org
Subject: RE: DTDs for VRML

Most elegant, Daniel! Good job.

In a mapping exercise, I map directly rather than
compressing to a higher metalevel. The reason is simply the
least astonishment principle. I like the node approach but
metalevels and attribute assignments for types makes the use
of a generalized editor like EMACS, Softquad AE, ArborText, etc.
harder because it produces very long lists of options which may
or may not apply. I also leave parameter entities out until
the tree is cooked completely. While some schools teach
the use of PEs for design elements, it can lead to obscure
DTDs. I do that last after everyone understands
each element type (otw, they spend a lot of time
scanning up and down the page). Afterwards, PEs make
a DTD more maintainable, but that is about the only
advantage to them. IMO, a DTD has to get very large
to make that worthwhile or be designed for modularity
which is a different issue.

That is, in DTD design (elder school) since
I consider the use of generalized editors, I try to
make each production as tight (say, individual)
as possible and recognizable. The size of the
DTD is trivial compared to the potential for creating a
valid but semantically bogus file; it is a good tradeoff.
There is not only readability but tool-based editability and using
the DTD to constrain the author. Consider the range from
the 3DML approach of very high level blocks to the
direct map to the metalevel map. We are along that
continuum.

If one does a direct map, hand editing
is easier in XML than in VRML97 or the metalevel
approach.... but only in the same way HTML is
easy to handedit. Since we lose some things
like the geometry keyword and the double field
names (appearance Appearance), there are some
gains, but one still has to know the tree to edit by hand.
DTD-based editors constrain productions and that
is an advantage.

The argument for treating PROTOS as regular nodes is a good one. The
HyTime architectural forms advocates used the
AttributeAsSecondaryGenericIdentifier in their designs.
Again, a tradeoff and one which comes up when
folks want to make "everything attributes" (usually
folks with relational backgrounds) and others want
to make "everything elements" (usually folks with
an object-oriented background").

You are right that either XML approach leads to a file
significantly larger than VRML97. Compression
of XML appears to be quite good though so the overall
file size doesn't concern me except for sending uncompressed
files.

The "theoretical" geometry profile is from a draft
forwarded to me. I had to consider the use of namespaces for
modularization.
This is yet AnotherIssue but profiles/modularization using
DTDs is something most people have little experience with
here although it was common in SGML CALS systems.

Note that we both used the ID/IDREFs for DEF/USE. I also
used it for the switch. For DEF/USE, it is fine; the switch
is problematic in that the ID can REF any ID in the file and
is alphanumeric, so problematic as an index.

The datatype issues have been raised on XML-DEV. This
apparently won't be resolved until the schema proposals
are resolved. I *predict* a use of notations and references
to external specs. Hardwiring datatypes into XML directly
is a markup religious heresy. The approach you take is fine
for the node metalevel. Did you consider the use of #FIXED
attributes?

The use of a general DOM API will be painful as any general
API is. I'm not sure having a specific-EAI that has to be learned,
debugged, implemented, etc. is easy to weigh against one
in which code written for one XML applicatIon can be easily
reused in another as well as the expertise. Tradeoffs again
similar to considering treewalking code against using
SQL and forward cursors.

I agree that an XML version of VRML97 is of limited usefulness.
Given that there are no browsers for it, an XSL
transform (very nice BTW), is the practical application. I do
contend that if VRMLNG is to be XML (some say....), then
giving the list members alternatives from the classical
direct map to your jazzier meta-level approach to look at
is worthwhile. If nothing else, they will get better at
reading and understanding DTDs.

Len Bullard
Intergraph Public Safety
clbullar@ingr.com

Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h

> -----Original Message-----
> From: Daniel Lipkin [SMTP:DLIPKIN@us.oracle.com]
> Sent: Tuesday, December 15, 1998 11:07 AM
> To: enterprise@vrml.org
> Cc: DLIPKIN@us.oracle.com; Bullard, Claude L (Len)
> Subject: DTDs for VRML
>
> Len,
>
> Well, I guess it's time to have the DTD for VRML discussion!
> I'm moving the discussion to the enterprise mailing list
> so we can have a more focused group, and since it is
> part of our charter.
>
> By coincidence, I just finished putting together a DTD for
> VRML as an exercise. I'm including it here for comparison.
> Attached to this message are four files:
>
> vrml.dtd - DTD for fully representing VRML97 content
> example.wrl - simple VRML97 document
> example.xml - the same content expressed in XML
> vrml.xsl - preliminary XSL style sheet for translating
> the XML back into utf8 VRML
>
> Notice that my approach is very different from
> Len's (posted currently at
> http://ariadne.iz.net/~jeffs/vrmLab/Documentation/vrmlDTD.html).
> Mine is capable of representing all of VRML
> (Len's is just a subset conforming to a theoretical
> geometric profile), but Len's is arguably
> more readable/hand editable than mine.
>
> I still think there is little to no value in
> representing VRML97 in XML. (This may not
> be as true for VRMLng; we'll have to see).
> Some of my conclusions from builing this DTD:
>
> - the XML is bigger, difficult to read, and a
> pain to edit by hand
> - using DOM directly on the XML requires several
> additional levels of indirection compared to
> the equivalent EAI calls
> - there is still significant parser work required
> above and beyond the XML parsing to ensure that
> the VRML content is valid.
>
> BTW, I'll be happy to post all relevant documents
> to the enterprise site if folks find it helpful.
>
> Regards,
>
> -Daniel
>
>
------------------------------------------------------------------------
for list subscription instructions,
send email to dbwork-request@vrml.org with text "info"

------------------------------------------------------------------------
for list subscription instructions,
send email to dbwork-request@vrml.org with text "info"

------------------------------------------------------------------------
for list subscription instructions,
send email to dbwork-request@vrml.org with text "info"