Hi Sam, I like this approach, and have used it successfully before in tagged data representations. The challenge will be parsing the "foreign markup" in text format, if a some sort of record delimiters are not employed. It will be difficult to parse the foreign markup record s injected in the middle of an occi text document or stream. We will require a way to detect the beginning and end of the foreign markup in text (non XML) form. For occi text format, I suggest a tag "foreign markup" immediately followed by white space characters that are immediately followed by "foreign markup octet count" terminated by a colon ':'. The next character following the colon is the beginning of the foreign markup. The foreign markup continues "without interruption" in the context of the document. All "foreign markup" terminates with a CR/LF characters. The terminating CR/LF characters are NOT part of the "foreign markup octet count". OCCI markup and additional "foreign markup" MAY follow the CR/LF termination characters. Obviously, "without interruption" does not include transport level fragmentation, out of order delivery and network transport assembly. It also not not include operating system memory fragmentation. -gary Sam Johnston wrote:

Morning all,

Rather than try to define everything that could possibly occur (ala CIM) we decided a while back to use "open" registries which allow the specification to evolve over time. Anyone will be able to propose additions via a process TBD (e.g. rough consensus on a public list, dedicated expert, first in first served, etc.) and will either get them (or not) within 7-30 days.

Additionally we will require implementations to forward and ignore markup they don't understand - as opposed to stripping it or throwing errors. This works well for Atom which uses this wording <http://tools.ietf.org/html/rfc4287#section-6.3>:

6.3. Processing Foreign Markup

Atom Processors that encounter foreign markup in a location that is legal according to this specification MUST NOT stop processing or

signal an error. It might be the case that the Atom Processor is able to process the foreign markup correctly and does so. Otherwise, such markup is termed "unknown foreign markup".

When unknown foreign markup is encountered as a child of atom:entry,

atom:feed, or a Person construct, Atom Processors MAY bypass the markup and any textual content and MUST NOT change their behavior as a result of the markup's presence.

When unknown foreign markup is encountered in a Text Construct or

atom:content element, software SHOULD ignore the markup and process any text content of foreign elements as though the surrounding markup were not present.

We need something similar to go into the spec.

Sam

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

_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg