[dfdl-wg] Fw: location of the complexEndian example

[Mike Beckerle]

Strange. I sent this some days ago, but it bounced back today complaining 
about the domain in dfdl-wg at ggf.org.

Here is is again. I'll try gridforum.org domain this time.

...mikeb

-----------------------------------------------------------------------------------------

>From our call today, people asked where the complexEndian example went.... 


On gridforge, this zip file document 
https://forge.gridforum.org/docman2/ViewProperties.php?group_id=113&category_id=803&document_content_id=3809 


contains files named testComplexNum1.* and testComplexNumTypedef1.* 

Those are the files with my original mock-ups about extensions to add a 
"complexEndian" attribute. 


...mikeb 



"Westhead, Martin (Martin)" <westhead at avaya.com> 
Sent by: owner-dfdl-wg at ggf.org 
11/30/2005 01:12 PM 


To
<dfdl-wg at ggf.org> 
cc

Subject
[dfdl-wg] Telcon Notes








Present
-------
Mike Bekerle
Tara Talbott
Martin Westhead
Geoff Judd
Steve Hanson
Bob McGrath

Reports from Active Trackers
----------------------------

Scoping tracker is being worked on - no news.
Extensibility group is moving forward - nothing to report yet


Discussion of Geoff's documents
-------------------------------

Variables doc

Mike observed that variables could be used in place of his extensibility
proposal on annotations.

Martin asked about whether we wanted to include this in the standard. Is
the complexity worth the addition - the feeling of the meeting was
probably it was.

Martin proposed that instead of binding a variable value to an element,
the variable value should be set with an XPath expression. 

Discussed the question as to whether the variable value can be reset,
whether it can/should be scoped in the same way as annotation
attributes.

Next step will be for Geoff to revise the document to look at cases
where value may need to be reset and start to explore some of the
semantic issues involved.

Choices doc

Discriminator type - what if discriminator is not a string? For
efficiency can we handle discriminators that are integers?

Suggest that instead of discriminators being computed to strings they
are computed to an XPath value with its implied type so that numeric
discriminators do need to be converted to strings.

Wildcard docs

Group seemed fairly happy with this proposal as it stands. 



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/dfdl-wg/attachments/20051206/422f0981/attachment.html