|
Thanks Michael. I think my next step will be to document what
attributes of XDM should be maintained through serialization and what
will be dropped. I agree that Node Identity is not something that can reasonably be maintained. Ancestry is an interesting concept I hadn't considered ... e.g. if you serialize a node $node ... its not expected that a reconstituted XDM $node could evaluate $node/.. Schema equivilence is interesting, I was thinking of addressing (or punting !) that concept with type information. Ignoring (or assuming) common xsd:* types ... If for example a value is of type mytype:abc ... I think agree its a good presumption that the target environment has access to the same types. Otherwise we open the box of having to serialize all the type information along with the XDM values. Good call. David A. Lee dlee@calldei.com http://www.calldei.com http://www.xmlsh.org 812-482-5224 Michael Kay wrote: 9915B4B452614D82A6BFF53ABB33B7F2@Sealion" type="cite">Good start. The next section before you go into specification should perhaps be "Requirements", including assumptions and constraints. This might include statements such as: * Serialized XDM will retain information about the descendants of nodes in the sequence being serialized, but it will not retain information about their ancestors. * Serialized XDM will not retain information about node identity: that is, the recipient of the serialized XDM will not be able to determine whether two serialized elements originated from the same node or merely from two nodes that were deep-equal to each other. * The consumer of the serialized XDM is assumed to have access to the same schema as the producer of the serialized XDM: that is, a QName identifying a type is assumed to have the same meaning to both the producer and consumer. * If A and B are two XDM sequences, then xml-canonicalize(xdm-serialize(A))) is codepoint-equal to xml-canonicalize(xdm-serialize(B))) if and only if fn:deep-equal(A, B). [Actually, that's probably not a good requirement, because fn:deep-equal() discards comments and PIs and you probably don't want to do that]. These are just example statements, you might want to substitute different ones: they are just intended to illustrate the kind of thing that needs to be said. Regards, Michael Kay http://www.saxonica.com/ http://twitter.com/michaelhkay-----Original Message----- From: talk-bounces@x-query.com [mailto:talk-bounces@x-query.com] On Behalf Of David A. Lee Sent: 18 September 2009 22:07 Cc: talk@x-query.com; xml-dev@lists.xml.org; XProc Dev Subject: [xquery-talk] Re: [xml-dev] Serialization of XDM - Use cases /Proposal I have created a first pass at documenting the problem of XDM Serialization and created some use cases. I would love any feedback or comments. This is on a new wiki I created for this purpose. If you would like to comment directly on the wiki please reply to me and I will give you the invite code (due to the sad state of affairs anonymous comments and editing are disabled due to wiki-spam-bots. I've found spam within 5 minutes of opening a public wiki ... <sigh> ) http://xml.calldei.com/XDMSerialize I have NOT included a proposal for a format yet, I'd like to discuss the intent and use cases first before putting up a straw-man proposal. Thank you for any contribution ! I've CC'd this to xproc-dev because one of the use cases if for developers and integrators with XML Pipeline processors such as XProc David A. Lee dlee@calldei.com http://www.calldei.com http://www.xmlsh.org 812-482-5224 _______________________________________________ talk@x-query.com http://x-query.com/mailman/listinfo/talk_______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php |