OpenSimulator:Xml Serialization
From OpenSimulator
(Difference between revisions)
(New page: = Opensimulator Xml Serialization Format 3 = == Goals == * Attributes and elements should map 1-to-1 with normalized object structure and hence protocol fields * Xml should be as terse as ...) |
|||
| (13 intermediate revisions by one user not shown) | |||
| Line 1: | Line 1: | ||
| − | = Opensimulator Xml Serialization Format 3 = | + | '''Note: This proposal is old and proceeded no further.''' |
| − | == Goals == | + | |
| + | == Opensimulator Xml Serialization Format 3 == | ||
| + | === Goals === | ||
* Attributes and elements should map 1-to-1 with normalized object structure and hence protocol fields | * Attributes and elements should map 1-to-1 with normalized object structure and hence protocol fields | ||
| − | * Xml should be as terse as possible whilst | + | * Xml should be as terse as possible whilst generating intuitive results |
| − | * The xml format should weigh human readability against the cost of parsing and | + | * The xml format should weigh human readability against the cost of parsing and re-calculation |
| + | * The format should never introduce unintuitive constructs or cases | ||
| + | * The implicit defaults should always reflect Second Life GUI defaults | ||
| + | * Automatic Xml Serialization should never introduce explicit values that are identical to default values | ||
| + | ===Draft speculation=== | ||
| + | * Since there is three distinct flavours ("SL GUI values", "LSL PrimitiveParams values" and "Protocol values") of defining prims, we should accomodate for this, quite possibly by having separate tags, so the parser can use that to parse differently. | ||
| − | |||
| − | |||
| − | |||
Example: | Example: | ||
| − | <. | + | <Prim>0 <Vector><X>1.0</X><Y>1.0</Y><Z>1.0</Z></Vector> 10 0.5</Prim> could be a way to encapsulate a raw PrimitiveParams dump. |
| − | + | <os:Circle extrusion="straight"><Texture ... /></os:Circle> | |
| − | < | + | |
* The fields that are enumerated should be encoded as either element types, attribute strings or attribute numbers. The default should be attribute numbers. | * The fields that are enumerated should be encoded as either element types, attribute strings or attribute numbers. The default should be attribute numbers. | ||
| Line 19: | Line 22: | ||
<Tree ...> means PCode x (Tree) | <Tree ...> means PCode x (Tree) | ||
<Avatar ...> means PCode z (Avatar) | <Avatar ...> means PCode z (Avatar) | ||
| + | |||
| + | Example: | ||
| + | <... extrusion="straight" ...> means protocol value 0 (PathCurve.Straight) | ||
| + | <... extrusion="1" ...> means protocol value 1 (PathCurve.xxx) | ||
| + | |||
| + | ===Node types=== | ||
| + | * entity identifiers (LLUUID vs URI) | ||
| + | * permissions | ||
| + | * world, scene, avatar, object, part, shape | ||
| + | * texture definitions | ||
| + | |||
| + | ===TextureEntry=== | ||
| + | * The Texture entry should be constructed in line with how the faces are enumerated on an object, ie: every face that is optional in a TextureEntry array, should be defined as an omissible element with one or several 'Face' nodes. If possible, this will make the Texture Face enumeration simpler. | ||
| + | * The [http://wiki.secondlife.com/wiki/Category:LSL_Face Overview of LSL face enumeration] although this obviously is LSL biased. | ||
| + | * Some experimentation needs to be done as of how faces are allocated based on 'profile and extrusion'; there is really no documentation that has taken this approach. | ||
| + | |||
| + | For example, the 'hollow' will introduce faces only if hollow > 0. Hence, hollow chould be defined as | ||
| + | <Hollow size="20%"><Face color="#ffdd33"><Texture src="http://images.tribalmedia.se/textures/plywood.jp2"/></Face></Hollow> | ||
| + | as opposed to | ||
| + | <... hollow="20%" ...> | ||
| + | thus allowing the parsing logic to encapsulate what exact faceId the texture should go into. | ||
Latest revision as of 10:26, 29 August 2014
Note: This proposal is old and proceeded no further.
Contents |
[edit] Opensimulator Xml Serialization Format 3
[edit] Goals
- Attributes and elements should map 1-to-1 with normalized object structure and hence protocol fields
- Xml should be as terse as possible whilst generating intuitive results
- The xml format should weigh human readability against the cost of parsing and re-calculation
- The format should never introduce unintuitive constructs or cases
- The implicit defaults should always reflect Second Life GUI defaults
- Automatic Xml Serialization should never introduce explicit values that are identical to default values
[edit] Draft speculation
- Since there is three distinct flavours ("SL GUI values", "LSL PrimitiveParams values" and "Protocol values") of defining prims, we should accomodate for this, quite possibly by having separate tags, so the parser can use that to parse differently.
Example: <Prim>0 <Vector><X>1.0</X><Y>1.0</Y><Z>1.0</Z></Vector> 10 0.5</Prim> could be a way to encapsulate a raw PrimitiveParams dump. <os:Circle extrusion="straight"><Texture ... /></os:Circle>
- The fields that are enumerated should be encoded as either element types, attribute strings or attribute numbers. The default should be attribute numbers.
Example: <Object ...> means PCode 9 (Primitive) <Tree ...> means PCode x (Tree) <Avatar ...> means PCode z (Avatar) Example: <... extrusion="straight" ...> means protocol value 0 (PathCurve.Straight) <... extrusion="1" ...> means protocol value 1 (PathCurve.xxx)
[edit] Node types
- entity identifiers (LLUUID vs URI)
- permissions
- world, scene, avatar, object, part, shape
- texture definitions
[edit] TextureEntry
- The Texture entry should be constructed in line with how the faces are enumerated on an object, ie: every face that is optional in a TextureEntry array, should be defined as an omissible element with one or several 'Face' nodes. If possible, this will make the Texture Face enumeration simpler.
- The Overview of LSL face enumeration although this obviously is LSL biased.
- Some experimentation needs to be done as of how faces are allocated based on 'profile and extrusion'; there is really no documentation that has taken this approach.
For example, the 'hollow' will introduce faces only if hollow > 0. Hence, hollow chould be defined as
<Hollow size="20%"><Face color="#ffdd33"><Texture src="http://images.tribalmedia.se/textures/plywood.jp2"/></Face></Hollow>
as opposed to
<... hollow="20%" ...>
thus allowing the parsing logic to encapsulate what exact faceId the texture should go into.
