[occi-wg] Foreign markup and extensibility

[Gary Mazz]

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 at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg
>