[x3d-public] SourceForge repository, X3DMetadataNode refactoring?

[Don Brutzman]

moved to public list since general interest, also added geospatial group for GeoMetadata dialog below, they likely need to take up that issue.

On 4/14/2015 8:40 AM, Roy Walmsley wrote:
> Don,
>
> My SourceForge account name is "[*****]".

very good, you are added as a developer, thanks.

	https://sourceforge.net/projects/x3d/

> In the first instance I was indeed thinking along the lines of the DTD and schemas. And I would not want to change anything without close collaboration. I don't have the experience yet but I do recognise the dangers. I have noted that there is a lot of autogeneration – I like that a lot. The more, the better.

a further practice I try to follow is identifying TODO items even if we don't yet know the fix, so that we can keep track of issues and goals.

> I agree that the one to play with is version 3.4. At the moment I am playing with the schema (I have XMLSpy). At the same time I am also updating the Node Reference <http://www.web3d.org/wiki/index.php/Node_Reference> on the  public wiki. As well as generating my own development version of 19775-1 V3.4. My aim is to get everything consistent.

Very good, better and better.

> And the one item I would really like to discuss at the WG with you present is the introduction of an /X3DMetadataNode/ into V3.4. I think this is the most serious technical problem in the whole specification.

Thanks for the additional discussion yesterday after the regular Wednesday X3D working group call.

Summary:

a. We use "X3D*Object" when it is an abstract interface that might involve multiple inheritance, instead of "X3D*Node" when it is directly inheritable.  The terminology here is intended to be generic since exact mechanisms can vary according to the implementing programming language.

Annex 7. Core Component
http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/core.html

4.4.2.3 Interface hierarchy
http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/concepts.html#InterfaceHierarchy

b. 7.3.4 X3DMetadataObject might be changed to X3DMetadataNode if interface problems can be avoided.

c. No problems in that regard noted for

     7.4.1 MetadataBoolean
     7.4.2 MetadataDouble
     7.4.3 MetadataFloat
     7.4.4 MetadataInteger
     7.4.5 MetadataSet
     7.4.6 MetadataString

d. 7.4.7 WorldInfo inherits X3DInfoNode which is a different interface chain.  That might be more consistently refactored in a manner agreeable to everyone if we leave the actual fields in the node signature unchanged, so that no content is affected.

e. GeoMetadata is the other relevant node.  There are a few things questionable/irregular about handling of property name=value pairs in this node.

Annex 25 Geospatial component
http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geodata.html

GeoMetadata : X3DInfoNode {
   MFNode   [in,out] data     []
   SFNode   [in,out] metadata NULL [X3DMetadataObject]
   MFString [in,out] summary  []
   MFString [in,out] url      []   [URI]
}

> The summary string array contains a set of keyword/value pairs, with each keyword and its subsequent value contained in a separate string; i.e., there should always be an even (or zero) number of strings. This provides a simple, extensible mechanism to include metadata elements that are human-readable and easy to parse.

So the summary field is actually an undefined datatype, an array of 2-tuple strings, "MFVec2String" perhaps.

Further, handling isn't really "easy" at all if unique tool code (and even scene-by-scene author Script nodes) must always be written whenever someone wants to parse or write geospatial metadata for this node.

At a minimum I hope to see the defined values in table 25.5 promoted to first-class SFString fields so that authors and scripts might access them easily.  Possibly the entries need updating too.

http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geodata.html#t-keywordsandvalues

Not sure how many GeoMetadata nodes actually exist in content, but conversion would be straightforward.  This would not break existing content if we kept the (MFVec2String) MFString [in,out] summary field intact for definition of other properties.

f.  We might be able to accomplish this in X3D v3.4 if GeoMetadata is sorted out.  Any other metadata-related nodes to consider?

g.  I suggest that we must have our metadata approach unified no later than X3D v4.0 in order to properly align with HTML5 and related Web standards.

h.  Metadata nodes can be a brain teaser, here is an additional reference that may help some:  online chapter from our book.

X3D for Web Authors, Chapter 15 Metadata Information
http://x3dgraphics.com/chapters/Chapter15-MetadataInformation.html

> I will always advise of issues I come across. What I really need is for Len to complete the changes to the specification comment form. I am loath to enter lots of comments without the subject appearing automatically in the mailing list.

agreed, hopefully Leonard can accomplish this needed modification.  again thanks.

==============================================

> -----Original Message-----
> From: Don Brutzman [mailto:brutzman at nps.edu]
> Sent: 14 April 2015 15:49
> To: Roy Walmsley
> Cc: x3d at web3d.org
> Subject: Re: SourceForge repository
>
> Please advise your sourceforge account and I can add you to the developers list Roy.
>
> Wondering which documentation you are referring to?  The documentation referring to the X3D DTD and schemas?
>
> All of the documentation products are autogenerated.  Also there are many ways to make a mistake in the DTD and Schema, so I would prefer to collaborate with you on changes to those.  I have often found that running regression tests on our many examples will uncover unsuspected problems.  Further, we want the DTDs and schemas to be as reliable as possible since so many tools and players may depend on them for loading a scene.
>
> So it would be good to coordinate closely throughout any potential changes.
>
> Something new that gives us a bit more flexibility are the version 3.4 DTD and Schema.  Since these are experimental, that might make it easier to test potential changes.   Once we have something working, it is fairly straightforward for me to ripple a change backwards consistently through versions 3.0-3.3, and the changelog files reflect the versions affected by each change.
>
> Available online at
>
> http://www.web3d.org/specifications
>
> Version control of the master X3D DTD and Schema assets is maintained at https://sourceforge.net/p/x3d/code/HEAD/tree/www.web3d.org/specifications
>
> Any proposed DTD/schema changes that I've overlooked?  Please advise.  Have tried to keep up but messages from our bug-reporting page have been missing meaningful subject lines which makes them pretty hard to follow.  As ever, I would like bug reports to be visible publicly so that errors can can understood and fixed thoroughly/properly.
>
> Anything else that you were looking at?  Thanks for all scrutiny and improvements.
>
> On 4/13/2015 7:19 AM, Roy Walmsley wrote:
>
>> Don,
>
>>  From SourceForge I have checked out, using Subversion,  a working copy of the documentation. So I was wondering:
>
>> 1)Would I have permission to commit any changes (I have a live SourceForge account)?
>
>> 2)Would you want me to commit anything?
>
>> Obviously any commits could only be to approved changes, and there would also be the issue of updating the ‘specifications’ web page.

all the best, Don
-- 
Don Brutzman  Naval Postgraduate School, Code USW/Br       brutzman at nps.edu
Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman