VRML - ExternProto relative paths Contact vs Cortona

Author

ExternProto relative paths Contact vs Cortona

Steve Smith

2006-11-05, 11:33 pm

Contact and Cortona have always implemented relative paths to resources in
ExternProtos differently.
Cortona uses paths relative to the proto wrl file.
Contact uses paths relative to the file which references the proto file.
(What does Flux,Octaga,Freewrl,XJ3D do ?)

In the new version 5 Cortona browser, it has changed to matche Contact so I
assume that the Contact method was more conformant (?).

The problem for us is that this makes it amost impossible to manage a
complex library of Protos which are shared by different scenes. We use
Protos instead of inlines so that parameters can be passed to inserted
models. We now will have to add the path the proto location to every url and
change them all when the model is moved or edited (with Blender in our
case).

The only way of sharing the models across secenes would be to use resource
urls like "..\..\modelsLibrary\protos\chairs\chair01\fabric.jpg". !!!! Urgh
!!!!!.

Has anyone found a better work round to this ?

Also ..
When a Proto references another Proto are the paths relative to the calling
proto or the top wrl scene file ?

Thanks, as ever, in advance.

Steve

simon

2006-11-05, 11:33 pm

seems to me anything other than links being relative to the file they
are in, is ridiculous.

are you sure about this?

Braden McDaniel

2006-11-05, 11:33 pm

On Oct 17, 4:24 am, "Steve Smith" <gostu...@btinternet.com> wrote:
> Contact and Cortona have always implemented relative paths to resources in
> ExternProtos differently.
> Cortona uses paths relative to the proto wrl file.
> Contact uses paths relative to the file which references the proto file.
> (What does Flux,Octaga,Freewrl,XJ3D do ?)
>
> In the new version 5 Cortona browser, it has changed to matche Contact so I
> assume that the Contact method was more conformant (?).

You assume right. Relative URLs in PROTOs are properly resolved
relative to where the PROTO is instantiated. See 4.5.3 in the VRML97
spec.

> The problem for us is that this makes it amost impossible to manage a
> complex library of Protos which are shared by different scenes. We use
> Protos instead of inlines so that parameters can be passed to inserted
> models. We now will have to add the path the proto location to every url and
> change them all when the model is moved or edited (with Blender in our
> case).
>
> The only way of sharing the models across secenes would be to use resource
> urls like "..\..\modelsLibrary\protos\chairs\chair01\fabric.jpg". !!!! Urgh
> !!!!!.
>
> Has anyone found a better work round to this ?

"data" URIs offer some potential relief; but they aren't really a
solution (and I'm not sure how well the current crop of browsers
supports them).

The best thing to do is to refactor your PROTOs such that rather than
fully encapsulating external resources, they take them as parameters
upon instantiation.

> Also ..
> When a Proto references another Proto are the paths relative to the calling
> proto or the top wrl scene file ?

The latter, since instantiation doesn't actually happen until the
outermost PROTO is instantiated.

Braden

simon

2006-11-05, 11:33 pm

just read the RURL bits from vrml97 and x3d. ( see below )

wow not wonder the browser developers are confused.

i think what's trying to be said here, is that any URL's in the FIELDS
used to create an instance from an external proto, or sent as events to
one, or that are created by scripts, are relative to the creation of
the instance/script. which works out to be the same as the much
simpler, URL's are always relative to the file they are in, any other
behaviour would make protos useless and i think would actually go
against the RURL standard itself. i can't think it was meant to refer
to RURL actually in the body of the proto, although the wording can
really only be interpreted as just that.

spec excepts;

ISO/IEC 14772-1:1997
4.5.3 Relative URLs

Relative URLs are handled as described in 2.[RURL]. The base document
for EXTERNPROTO statements or nodes that contain URL fields is:

1. The VRML file in which the prototype is instantiated, if the
statement is part of a prototype definition.
2. The file containing the script code, if the statement is part of
a string passed to the createVrmlFromURL() or createVrmlFromString()
browser calls in a Script node.
3. Otherwise, the VRML file from which the statement is read, in
which case the RURL information provides the data itself.

ISO/IEC 19775-1:2004 part1
9.2.2 Relative URLs

Relative URLs are handled as described in 2.[RFC1808]. The base
document for nodes that contain URL fields is the X3D file from which
the statement is read. The base document for EXTERNPROTO statements or
nodes that contain URL fields is:

1. The X3D file in which the prototype is instantiated, if the
statement is part of a prototype definition.
2. The file containing the script code which created a new scene
graph.
3. Otherwise, the X3D file from which the statement is read, in
which case the RURL information provides the data itself.

Braden McDaniel

2006-11-05, 11:33 pm

On Oct 30, 1:20 pm, "simon" <psipl...@netscape.net> wrote:
> just read the RURL bits from vrml97 and x3d. ( see below )
>
> wow not wonder the browser developers are confused.

This has been clear since 1997. The text is unambiguous.

> i think what's trying to be said here, is that any URL's in the FIELDS
> used to create an instance from an external proto, or sent as events to
> one, or that are created by scripts, are relative to the creation of
> the instance/script. which works out to be the same as the much
> simpler, URL's are always relative to the file they are in, any other
> behaviour would make protos useless and i think would actually go
> against the RURL standard itself.

I don't see any basis in the spec prose for that interpretation; so I'm
not sure why you think that.

> i can't think it was meant to refer
> to RURL actually in the body of the proto, although the wording can
> really only be interpreted as just that.

As someone who was around when that text was being debated, I assure
you that it means what it says.

Braden

simon

2006-11-05, 11:33 pm

>> This has been clear since 1997. The text is unambiguous.

what!!, it's practically gibberish, and with both major browser
developers apparently unable to interpret it over all these years, i
can't see how you can say that.

In my experience sometimes something seems obvious until you are shown
the alternatives, this is why standard writing is really really
difficult.

so here's interpretations to consider;

1. "Relative URLs are handled as described in 2.[RURL]." which says
url's are relative to the file they are in, if you indicate compliance
to a standard it's 100%.

2. "EXTERNPROTO statements or nodes" - externprotos are a list of
fields types, names and a link to the proto, where are the nodes
referred to here? and if this is broken then the option list below it
is meaningless, because you don't know clearly what it refers too.

3. "in which case the RURL information provides the data itself" what
like a data url? can't be, but that's what it says.

i know my reinterpretation at what it SHOULD mean is very brash, based
on throwing the whole section out as having no clear meaning, but
that's only because, at this point, the 'best guess' appears to be a
complete, and pointless, disaster for proto reuse.

the real issue, of what you do with strings that are passed and then
used in url fields or url fields that are passed and used as strings,
is not even considered.

simon

Braden McDaniel

2006-11-05, 11:33 pm

On Tue, 31 Oct 2006 13:02:26 -0800, simon wrote:

>
> what!!, it's practically gibberish,

That assertion appears to be completely unfounded.

> and with both major browser
> developers apparently unable to interpret it over all these years, i
> can't see how you can say that.

You're jumping to conclusions in assuming that a failure to conform was
the result of misinterpreting the spec.

> In my experience sometimes something seems obvious until you are shown
> the alternatives, this is why standard writing is really really
> difficult.
>
> so here's interpretations to consider;
>
> 1. "Relative URLs are handled as described in 2.[RURL]." which says
> url's are relative to the file they are in, if you indicate compliance
> to a standard it's 100%.

Your assertion has no basis in fact.

What rfc 1808 actually says is (3.1):

Within certain document media types, the base URL of the document can be
embedded within the content itself such that it can be readily obtained
by a parser. This can be useful for descriptive documents, such as tables
of content, which may be transmitted to others through protocols other
than their usual retrieval context (e.g., E-Mail or USENET news).

It is beyond the scope of this document to specify how, for each media
type, the base URL can be embedded.

The last sentence there is why the VRML97 spec comes out and tells you
point blank what the base document is (for model/vrml).

> 2. "EXTERNPROTO statements or nodes" - externprotos are a list of
> fields types, names and a link to the proto, where are the nodes
> referred to here? and if this is broken then the option list below it
> is meaningless, because you don't know clearly what it refers too.

The "nodes" referred to are nodes that appear anywhere nodes can legally
appear. I don't understand what you think is broken.

> 3. "in which case the RURL information provides the data itself" what
> like a data url? can't be, but that's what it says.

That is a bit unclear. The term "RURL information" is vague; though
what's even less clear to me is how you get to "data" URLs from this
prose, since they have no notion of being relative.

What *is* clear is the first part of the sentence in which the above quote
appears, "Otherwise, the VRML file from which the statement is read...,"
identifying the base document when the statement is not part of a PROTO, a
script, or input to createVrmlFrom* functions (cases covered by the
previous two bullet points).

> i know my reinterpretation at what it SHOULD mean is very brash, based
> on throwing the whole section out as having no clear meaning, but
> that's only because, at this point, the 'best guess' appears to be a
> complete, and pointless, disaster for proto reuse.

That PROTOs can't be used exactly the way you thought hardly amounts to a
"disaster".

And you have not made any reinterpretation; you've simply stated what you
wish the spec said. There is no spec prose supporting your position; thus
you haven't interpreted anything.

Your characterization of honoring what the spec clearly states is the base
document for a relative URL as a "best guess" is nothing short of
irrational; and I think insulting to persons who understand written
English. I don't see any point in continuing a discussion where the spec
prose is being deliberately ignored.

--
Braden McDaniel e-mail: <braden@endoframe.com>
<http://endoframe.com> Jabber: <braden@jabber.org>

simon

2006-11-05, 11:33 pm

>
> The last sentence there is why the VRML97 spec comes out and tells you
> point blank what the base document is (for model/vrml).
>

model/vrml is not a protocol, it is a mime type, vrml is normally
delivered over http, the same as html.

>
> The "nodes" referred to are nodes that appear anywhere nodes can legally
> appear. I don't understand what you think is broken.
>

EXTERNPROTO can not legally have any nodes. are you confusing
EXTERNPROTO and the proto being refer to by it?

>
> That is a bit unclear. The term "RURL information" is vague; though
> what's even less clear to me is how you get to "data" URLs from this
> prose, since they have no notion of being relative.
>
> What *is* clear is the first part of the sentence in which the above quote
> appears, "Otherwise, the VRML file from which the statement is read...,"
> identifying the base document when the statement is not part of a PROTO, a
> script, or input to createVrmlFrom* functions (cases covered by the
> previous two bullet points).
>
>
> That PROTOs can't be used exactly the way you thought hardly amounts to a
> "disaster".
>

as this stands they can hardly be used at all, externally, so i think
disaster is quite appropriate.

> And you have not made any reinterpretation; you've simply stated what you
> wish the spec said. There is no spec prose supporting your position; thus
> you haven't interpreted anything.
>

i 'reinterpret' because whats written has a low level of clarity, so it
can be easily interpreted many ways, which is the problem.

> Your characterization of honoring what the spec clearly states is the base
> document for a relative URL as a "best guess" is nothing short of
> irrational; and I think insulting to persons who understand written
> English. I don't see any point in continuing a discussion where the spec
> prose is being deliberately ignored.
>

"irrational" and "insulting", are you implying i'm stupid for not
understanding this, just stating that would in fact be clearer prose.

interpreting a human language is always some sort of guess, i think
maybe you are missing this fundamental realization.

but i would still really like to find out what the reason for this is,
how people feel about it and what can be done, not interpretating the
spec., so i'm starting a new topic.

simon

simon

2006-11-05, 11:33 pm

> (What does Flux,Octaga,Freewrl,XJ3D do ?)

flux 3,( just out ) does it the sensible way, the way Cortona 5 now
doesn't.

simon

2006-11-05, 11:33 pm

see;
http://groups.google.co.uk/group/co...ef643e4697b32c3

simon

2006-11-05, 11:33 pm

how i see the light

see;
http://xsun.sdct.itl.nist.gov/~mkas...XTERNPROTO.html

according to the interpretation here, this is all about the string at
the end of an EXTERNPROTO statement, and has nothing to do with URL's
in the body of the proto, and since this isn't claiming to be a URL it
all works.

but that means that Cortona has just broken their bowser!!

simon.

Braden McDaniel

2006-11-05, 11:33 pm

On Wed, 01 Nov 2006 07:40:51 -0800, simon wrote:

>
> model/vrml is not a protocol, it is a mime type, vrml is normally
> delivered over http, the same as html.

Stop posting nonsense and read rfc 1808--at *least* the part I quoted,
for heaven's sake, which included the term "media type" (which is what
"model/vrml" is).

>
> EXTERNPROTO can not legally have any nodes. are you confusing
> EXTERNPROTO and the proto being refer to by it?

I can't make any sense of what you're saying here. Obviously EXTERNPROTO
statements do not include node statements; but that bit of trivia is quite
irrelevant to the point at hand.

"EXTERNPROTO statements" and "nodes that contain URL fields" are the two
elements of VRML97 syntax where URLs (relative or otherwise) can appear;
and thus, the two places where a base document needs to be established.
What *exactly* is your problem with this?

>
> as this stands they can hardly be used at all, externally, so i think
> disaster is quite appropriate.

Of course they can. You either avoid external references in PROTOs
(i.e., "data" URLs, inline scripts, PixelTexture nodes), or you factor
things such that references to external resources are given as field
values at the instantiation point (as I mentioned a lot closer to the top
of this thread).

>
> i 'reinterpret' because whats written has a low level of clarity, so it
> can be easily interpreted many ways, which is the problem.

So *you* claim. In nearly 10 years of acquaintance with this prose, you're
the first person I've ever seen claim it's ambiguous. And you're far from
the first to be unhappy with what it says; so I don't think that's due to
obscurity.

>
> "irrational" and "insulting", are you implying i'm stupid for not
> understanding this, just stating that would in fact be clearer prose.

I do not mean to imply that you are stupid. I'm implying that you're
deliberately refusing to acknowledge what's plainly written because you
don't like it.

--
Braden McDaniel e-mail: <braden@endoframe.com>
<http://endoframe.com> Jabber: <braden@jabber.org>

Braden McDaniel

2006-11-05, 11:33 pm

On Wed, 01 Nov 2006 15:23:32 -0800, simon wrote:

> how i see the light
>
> see;
> http://xsun.sdct.itl.nist.gov/~mkas...XTERNPROTO.html
>
> according to the interpretation here, this is all about the string at
> the end of an EXTERNPROTO statement, and has nothing to do with URL's
> in the body of the proto, and since this isn't claiming to be a URL it
> all works.
>
> but that means that Cortona has just broken their bowser!!

That test suite is not authoritative. So obviously if it says something
contrary to the spec, believe the spec.

I say that because I've been through every test in that suite at least
once--probably twice (and more than that for parts of it)--and I know for
a fact it has quite a few errors in it. However, in this particular case, I
cannot find anything in the document at that URI that supports your
assertion.

You should pay special attention to test 7. But look out for 8; it does
have a problem: it confuses lexical placement with instantiation. (The
former is what happens when you write syntax; the latter is what happens
when you render the VRML.) It may be the case that the spec needs to be
clearer about what constitutes instantiation of a node and when it happens.

--
Braden McDaniel e-mail: <braden@endoframe.com>
<http://endoframe.com> Jabber: <braden@jabber.org>

simon

2006-11-05, 11:33 pm

Braden McDaniel wrote:

> On Wed, 01 Nov 2006 15:23:32 -0800, simon wrote:
>
>
> That test suite is not authoritative. So obviously if it says something
> contrary to the spec, believe the spec.
>

the spec. IS ambiguous, i now believe it is you who are probably
contrary to the spec. and that this site has used the most obviously
correct interpretation.

please for the sake of VRML itself try to see it.

> I say that because I've been through every test in that suite at least
> once--probably twice (and more than that for parts of it)--and I know for
> a fact it has quite a few errors in it. However, in this particular case, I
> cannot find anything in the document at that URI that supports your
> assertion.
>

test 7. this is not a spec and so doesn't spell things out, you have
to try to work out what the person writing the tests was trying to do,
in this case not looking at internal URL's seems to me to clearly
indicate that he thought they were unaffected and so didn't need
testing.

> You should pay special attention to test 7. But look out for 8; it does
> have a problem: it confuses lexical placement with instantiation. (The
> former is what happens when you write syntax; the latter is what happens
> when you render the VRML.) It may be the case that the spec needs to be
> clearer about what constitutes instantiation of a node and when it happens.
>
> --

pointless nip picking of an irrelevant issue.

Steve Smith

2006-11-05, 11:33 pm

I can see this one will run and I run.
How about we ask the browser developers to use an embed option to switch
this behavior ?

"Steve Smith" <gostudio@btinternet.com> wrote in message
news:p-SdnReEHZPMDqnYnZ2dnUVZ8tCdnZ2d@bt.com...
> Contact and Cortona have always implemented relative paths to resources in
> ExternProtos differently.
> Cortona uses paths relative to the proto wrl file.
> Contact uses paths relative to the file which references the proto file.
> (What does Flux,Octaga,Freewrl,XJ3D do ?)
>
> In the new version 5 Cortona browser, it has changed to matche Contact so
> I assume that the Contact method was more conformant (?).
>
> The problem for us is that this makes it amost impossible to manage a
> complex library of Protos which are shared by different scenes. We use
> Protos instead of inlines so that parameters can be passed to inserted
> models. We now will have to add the path the proto location to every url
> and change them all when the model is moved or edited (with Blender in our
> case).
>
> The only way of sharing the models across secenes would be to use resource
> urls like "..\..\modelsLibrary\protos\chairs\chair01\fabric.jpg". !!!!
> Urgh !!!!!.
>
> Has anyone found a better work round to this ?
>
> Also ..
> When a Proto references another Proto are the paths relative to the
> calling proto or the top wrl scene file ?
>
> Thanks, as ever, in advance.
>
> Steve
>
>

Joerg Scheurich aka MUFTI

2006-11-05, 11:33 pm

> the spec. IS ambiguous, i now believe it is you who are probably
> contrary to the spec. and that this site has used the most obviously
> correct interpretation.

I think, the specs is not ambiguous, but broken 8-(

| 4.5.3 Relative URLs
|
| Relative URLs are handled as described in 2.[RURL]. The base document for
| EXTERNPROTO statements or nodes that contain URL fields is:
|
| 1. The VRML file in which the prototype is instantiated, if the statement
| is part of a prototype definition.

So what is a "prototype definition" ?

http://www.web3d.org/x3d/specificat...epts.html#4.3.5

| 4.3.5 PROTO statement syntax
|
| A PROTO statement consists of the PROTO keyword, followed in order by the
| prototype name, prototype interface declaration, and prototype definition:
|
| PROTO <name> [ <declaration> ] { <definition> }

It is hard to believe, that the authors of the standard really intended to
make EXTERN stored PROTO practically unuable for containing Inline,
Texture, Multimedia etc. files in a usefull modular way.

The need to fill the Interface of a PROTO with tons of URLs for contained
Textures of a PROTO with a complex object is not a usefull modular way of
this technology.

If 4.5.3 would read

| 1. The VRML file in which the prototype is instantiated, if the statement
| is part of a prototype declaration.

instead of

| 1. The VRML file in which the prototype is instantiated, if the statement
| is part of a prototype definition.

all would be well.

So should we believe in the words or in the spirit of the VRML97 standard ?
What is more holy ?

We will know, if the upcoming error-clearance of the current X3D standard
will change the word "definition" to the word "declaration" in X3D
chapter 9.2.2 ...

so long
MUFTI
--
Warning: If a process happens to return STILL_ACTIVE (259) as an error code,
applications that test for this value could end up in an infinite loop.
(Aus einer Micro$oft Dokumentation fuer GetExitCodeProcess)

simon

2006-11-05, 11:33 pm

>
> | 4.5.3 Relative URLs
> |
> | Relative URLs are handled as described in 2.[RURL]. The base document for
> | EXTERNPROTO statements or nodes that contain URL fields is:
> |
> | 1. The VRML file in which the prototype is instantiated, if the statement
> | is part of a prototype definition.
>
> So what is a "prototype definition" ?
>

i think if you concentrate on the "EXTERNPROTO" bit, all the three
points can be seen as refering the just that and not to an actual
proto referer to by it, then the "prototype definition" refers to the
EXTERNPROTO being inside another proto, and this makes sense because
there is a problem with this that this cures, and then its clear that
point 1. is not refering to URL's in protos at all but to the string at
the end of the EXTERNPROTO statement, that is taken like a URL but is
really not one by the standard for URL's, when this is then IN the
containing protos definition.

the link i gave previously to tests, shows their developer understood
this and it was only reading the tests that i was able to grasp it.

>
> | 4.3.5 PROTO statement syntax
> |
> | A PROTO statement consists of the PROTO keyword, followed in order by the
> | prototype name, prototype interface declaration, and prototype definition:
> |
> | PROTO <name> [ <declaration> ] { <definition> }
>
> It is hard to believe, that the authors of the standard really intended to
> make EXTERN stored PROTO practically unuable for containing Inline,
> Texture, Multimedia etc. files in a usefull modular way.
>
> The need to fill the Interface of a PROTO with tons of URLs for contained
> Textures of a PROTO with a complex object is not a usefull modular way of
> this technology.
>
> If 4.5.3 would read
>
> | 1. The VRML file in which the prototype is instantiated, if the statement
> | is part of a prototype declaration.
>
> instead of
>
> | 1. The VRML file in which the prototype is instantiated, if the statement
> | is part of a prototype definition.
>
> all would be well.
>
> So should we believe in the words or in the spirit of the VRML97 standard ?
> What is more holy ?
>

if you read the standard as above then all it is OK, and it works to
the spirit of the spec., then the only problem apart from the terrible
lack of clarity, is that the Contact and now the Cortona developers
seem to of misunderstood this.

So all we need is this section clarified. by someone who understands
it!!!!

simon

simon

2006-11-05, 11:33 pm

Steve Smith wrote:

> I can see this one will run and I run.
> How about we ask the browser developers to use an embed option to switch
> this behavior ?
>

no, the spec. has to be clarified, and then, hopefully, the browsers
will be able to all get it right.

i know how much of a pain it is in this case, but the best way forward
is to build to the spec. and use a compliant browser, if you must use a
non-compliant browser then still develop in the best compliant way and
produce a special version with a work round, like putting all the files
in the same directory, and wait for the browser you need to do it
right.

simon.

Russ

2006-11-05, 11:33 pm

Ok well, I haven't read this entire thread.
I simply don't have the time.
But I do know what works in terms of ExternProto paths
for getting stuff to work cross-browser wise.
The following url is quite extensive in the nested use of
ExternalProtos
It works in the three "C" browsers:
http://mysite.verizon.net/pyth7/Mus...en_Syzygies.htm

It hasn't been fully debugged yet for Octaga or Flux, but I am working
on that.
Both those browsers have no problems loading the ExternalProtos though
- the
bugs are else where.
I don't think FreeWRL is robust or compliant enough to handle the url.

tc
Russ Kinter

simon wrote:
> Steve Smith wrote:
>
>
> no, the spec. has to be clarified, and then, hopefully, the browsers
> will be able to all get it right.
>
> i know how much of a pain it is in this case, but the best way forward
> is to build to the spec. and use a compliant browser, if you must use a
> non-compliant browser then still develop in the best compliant way and
> produce a special version with a work round, like putting all the files
> in the same directory, and wait for the browser you need to do it
> right.
>
> simon.

Braden McDaniel

2006-11-05, 11:33 pm

On Nov 2, 9:00 am, Joerg Scheurich aka MUFTI
<rusmu...@helpdesk.bera.rus.uni-stuttgart.de> wrote:

[snip]

> It is hard to believe, that the authors of the standard really intended to
> make EXTERN stored PROTO practically unuable for containing Inline,
> Texture, Multimedia etc. files in a usefull modular way.
>
> The need to fill the Interface of a PROTO with tons of URLs for contained
> Textures of a PROTO with a complex object is not a usefull modular way of
> this technology.
>
> If 4.5.3 would read
>
> | 1. The VRML file in which the prototype is instantiated, if the statement
> | is part of a prototype declaration.
>
> instead of
>
> | 1. The VRML file in which the prototype is instantiated, if the statement
> | is part of a prototype definition.
>
> all would be well.
>
> So should we believe in the words or in the spirit of the VRML97 standard ?
> What is more holy ?

The language in the spec matches the intent; this had no shortage of
discussion when the language was originally being hashed out.

At the time, browser developers insisted that it was problematic for an
implementation to carry around an arbitrary number of base documents.
To put that a little more cynically, multiple base documents simply
didn't jive with the Cosmo developers' mental model of PROTO. (Keep in
mind that the mental model of VRML had by these developers *is* what
underlies the vast majority of the prose in the VRM97 spec.)

At this point, the existing semantic has been with us for nearly 10
years. Arguments about its technical merit are moot. The ship sailed a
long, long time ago.

As far as X3D is concerned, developers unhappy with the RURL semantics
for PROTOs would probably be better served by Inline with IMPORT and
EXPORT.

Braden

simon

2006-11-05, 11:33 pm

Russ wrote:

> Ok well, I haven't read this entire thread.
> I simply don't have the time.
> But I do know what works in terms of ExternProto paths
> for getting stuff to work cross-browser wise.
> The following url is quite extensive in the nested use of
> ExternalProtos
> It works in the three "C" browsers:
> http://mysite.verizon.net/pyth7/Mus...en_Syzygies.htm
>
> It hasn't been fully debugged yet for Octaga or Flux, but I am working
> on that.
> Both those browsers have no problems loading the ExternalProtos though
> - the
> bugs are else where.
> I don't think FreeWRL is robust or compliant enough to handle the url.
>
> tc
> Russ Kinter

all the files in this seem to be in the same directory, so this problem
doesn't come up, i quess your cross browser compatability is about
other issues.

simon.

simon

2006-11-05, 11:33 pm

OK, please, using your 10 years of experience of this, tell me what
this sentence added to the spec for the X3D version is meant to
mean/clarify. It seems to of been added specifically to prevent the
interpretation you are making.

(note this is a complete sentence with no context other then it applies
to all relative URL's)

"The base document for nodes that contain URL fields is the X3D file
from which
the statement is read."

simon.

degorg@gmail.com

2006-11-19, 7:36 pm

Josip Almasi wrote:
> Right, it's broken in many ways.

Some more examples, please.

> Check i.e. this thread, when Dmitry Egorenkov of ParallelGraphics so
> elaboratelly explains why losing events isn't a bug but a feature:
> http://www.web3d.org/x3d/publiclist...3/msg00118.html

If you carefully reread this message, you'll understand that Cortona
doesn't lose events, but Contact violates standard sending two events
instead of one.

Dmitry Egorenkov

simon

2006-11-19, 7:36 pm

just for info, i think this is probably how the spec should of phrased
it:

from
"http://xsun.sdct.itl.nist.gov/~mkass/x3d/Misc/EXTERNPROTO/Requirements.html"

<quote>

# If an EXTERNPROTO statement is nested in a PROTO definition, the
EXTERNPROTO relative URL will be considered relative to the base URL of
the VRML file in which the enclosing PROTO is instantiated.

# An EXTERNPROTO relative URL generated by a Script node ( via
createVrmlFromURL() or createVrmlFromString () browser calls ), will be
considered relative to the base URL of the file containing the script
code.

# An EXTERNPROTO relative URL will be considered relative to the file
from which it is read if it is not nested in a PROTO definition, and is
not generated by a Script node.

</quote>

Josip Almasi

2006-11-19, 7:36 pm

degorg@XXXXXXXXXX wrote:
> Josip Almasi wrote:
>
>
> Some more examples, please.

Oh I gave up cortona almost two years ago, maybe you should have asked
earlier:)
You probably fixed some of 'features' in the meantime, like hangs when
enventin comes during viewpoint transitions, so my examples would be
obsolete anyway.
So I'll just keep satisfaction in saying that I gave up cuz its broken:)

>
> If you carefully reread this message, you'll understand that Cortona
> doesn't lose events, but Contact violates standard sending two events
> instead of one.

Yes I have read it back in march 2005; as I said, you have so
elaboratelly explained that this 'feature' makes cortona spec compliant.
Thank you for the additionally letting us know that unlike cortona,
contact isn't compliant...

Regards...

simon

2006-11-19, 7:36 pm

>
> Yes I have read it back in march 2005; as I said, you have so
> elaboratelly explained that this 'feature' makes cortona spec compliant.
> Thank you for the additionally letting us know that unlike cortona,
> contact isn't compliant...
>
> Regards...

with all the discussion on bugs/features/compliance over the years, it
seems strange no one has set up a page to track these things, maybe no
one wants to put people off VRML? so every new user has to rediscover
the issues, and then spend the majority of their time trying to get
cross-browser support, which usually just means limiting themselves to
only the really simple things.

to get the ball rolling, here's a summary,from memory, of what bugs
have seriously bitten me:

Contact bugs:

- all nodes at the root of a proto are, incorrectly, visible
- making multiple instances doesn't work if scripts are involved
- concave extrusion ends don't work.
- transparent textures viewed through transparent textures don't work
- doesn't recognise bit 31 ( top bit ) of int32 type
- won't allow statements outside functions in script nodes
and of course;
- relative URL's in proto not relative to file they are in.

Josip Almasi

2006-11-19, 7:36 pm

simon wrote:
>
> with all the discussion on bugs/features/compliance over the years, it
> seems strange no one has set up a page to track these things, maybe no
> one wants to put people off VRML? so every new user has to rediscover

Well I can speak only for myself... I was simply - lazy:)
IOW _maintaining_ such a compatibility listing is a job for itself.
And in general, proprietary software vendors don't like such listings.

> the issues, and then spend the majority of their time trying to get
> cross-browser support, which usually just means limiting themselves to
> only the really simple things.

They either limit themselves to really simple things or stick to one
browser, abandoning the standard.
VRML isn't the only such standard; try i.e. writing db apps using
standard SQL...

Regards...

simon

2006-11-19, 7:36 pm

> standard; try i.e. writing db apps using
> standard SQL...
>

have done, pathetic isn't it.

simon.

Braden McDaniel

2006-11-19, 7:36 pm

On Fri, 10 Nov 2006 18:10:35 +0100, Josip Almasi wrote:

> simon wrote:
>
> Well I can speak only for myself... I was simply - lazy:)
> IOW _maintaining_ such a compatibility listing is a job for itself.
> And in general, proprietary software vendors don't like such listings.

I don't think that's true. As long as the list is honest and accurate,
it's a boon both to users and to the developers of the software. Many
years ago, when CSS was a nascent technology, I created a page documenting
the shortcomings of Internet Explorer 3.0 with respect to that
specification. The response--even from the IE developers--was quite
positive. The fact is that even if such a list doesn't inform the
developers of any shortcomings they don't already know about, it does
provide a good indicator of what shortcomings users are really
encountering.

But you have to be intellectually honest. You cannot approach such a task
with an axe to grind against a particular vendor; and you cannot use it
as a platform to promote particular nonstandard behavior that you are fond
of for whatever reason. *That* will annoy vendors and probably only have
the effect of lowering your own credibility. (Hint, hint: Stop claiming
Cortona is "broken" when you can't back up that claim with spec prose.)

But you are absolutely right that maintaining such a list is a *lot* of
work. Making it Actually Useful requires time, dedication, and a
fascination with minutia.

--
Braden McDaniel e-mail: <braden@endoframe.com>
<http://endoframe.com> Jabber: <braden@jabber.org>

simon

2006-11-19, 7:36 pm

> But you are absolutely right that maintaining such a list is a *lot* of
> work. Making it Actually Useful requires time, dedication, and a
> fascination with minutia.
>
> --

I've been wondering if we could do this as a community effort, after
all most people probably remember some pet hates or something that bit
them hard, so can jot down an explanation quite quickly and its just
that sort of basic information gathering that would take the time.

It's not ideal but the simplest way to start could be here, start a
thread that explains the aim, then have all replies to that indicate
the browser in question ( they could be filled in to start with ), then
under that the supposed bugs, then under that any discussion. Any spam
/ misuse / partisan / confused entries could be flushed by rebuilding
the entire thread without the crap, and then just ignoring the older
thread, maybe with an obsolete indication at its end. The effort of
doing that having some preventative effect on being re-spammed etc.

Josip Almasi

2006-11-19, 7:36 pm

Braden McDaniel wrote:
>
> I don't think that's true. As long as the list is honest and accurate,
> it's a boon both to users and to the developers of the software. Many
....

I'd sure value such a list as a developer too.
However, company interests don't mean neither user nor developer
interests. I usually don't read licenses, but I've *heard* of licenses
that prohibit publishing benchmark results etc... for what reason I
wonder?;)

> But you have to be intellectually honest. You cannot approach such a task
> with an axe to grind against a particular vendor; and you cannot use it
> as a platform to promote particular nonstandard behavior that you are fond
> of for whatever reason. *That* will annoy vendors and probably only have
> the effect of lowering your own credibility. (Hint, hint: Stop claiming
> Cortona is "broken" when you can't back up that claim with spec prose.)

Well somehow I don't care that much for my credibility LOL:)

Yes such a list is a task for a consortium's task group.

Regards...

Josip Almasi

2006-11-19, 7:36 pm

simon wrote:
>
> I've been wondering if we could do this as a community effort, after
> all most people probably remember some pet hates or something that bit
> them hard, so can jot down an explanation quite quickly and its just
> that sort of basic information gathering that would take the time.
>
> It's not ideal but the simplest way to start could be here, start a
> thread that explains the aim, then have all replies to that indicate
> the browser in question ( they could be filled in to start with ), then
> under that the supposed bugs, then under that any discussion.

.... and then make snippets, that's what we called these back in the day
when fidonet ruled.
Yes that could work, provided there's contributors and maintaners.
As for me, I'm gonna contribute to your effort by bitching more about
bugs from now on:)

Regards...