> > If you want, WMLC is a WBXML application.
>
> So the relationship between WBXML and WMLC is somewhat like the
> relationship between SGML and HTML, in that WBXML and SGML
> aren't markup
> languages that define specific tags, they're types of "meta-languages"
> that, when combined with a DTD or whatever, result in
> languages that are
> applications of the underlying "meta-language".
>
> If so, then might there be a WMLC dissector that, for
> instance, uses the
> common WBXML code but supplies some additional information to
> allow the
> WMLC semantics to be understood - and possibly dissectors for
> the other
> WBXML applications as well?
Well, the way I was looking at it was to parse the WBXML content
in 2 "steps". First, the WBXML "skeleton" is constructed, and then
the content-specific (WMLC, SIC, ...) mapping of application-specific
elements on top of the WBXML "skeleton" is performed.
This mapping can occur automatically, e.g., by referring to an array
of value_string arrays when doing the proto_tree_add_XXX () magic.
Depending on the content type, the mapping will be performed (if
it is available). One could also take a fallback mapping table in
case that specific content did not have a matching value_string array
yet. In this situation, a structure with tag and attribute names like
"tag_6", "attr_start_45" and "attr_value_22" would be defined.
It would be possible to set preference parameters for enabling/disabling
both WBXML in-depth parsing and WBXML application "rendering", in order
to significantly change memory and CPU consumption while E.g., doing
live captures.
The final output in Ethereal might look like:
Tag with Content: <wml>
Tag with Attributes and Content: <card
Attribute-Start: title=
STR_I "Google"
END of Attribute List: >
Tag with Attributes and Content: <do
Attribute-Start: type="accept"
Attribute-Start: label=
STR_I "OK"
END of Attribute List: >
Empty Tag: <noop/>
END of Tag: </do>
Tag with Attributes and Content: <do
Attribute-Start: type="options"
Attribute-Start: label=
STR_I "Terug"
END of Attribute List: >
Empty Tag: <prev/>
END of Tag: </do>
[ . . . ]
One could put both WBXML "skeleton" and WBXML application "rendering"
either next to each other as shown in the example above, or in two
separate (sub)trees of the WBXML tree:
[+] Data
[+] WBXML skeleton
[+] WML rendering
(in case the content is WMLC).
Unfortunately, the rendering of the content will require recursion
(when tag content is a tag: see indentation of example), otherwise
we can only parse single WBXML tokens.
Regards,
Olivier
