Full validation of Atom feeds containing extensions using NVDL
CC Attribution - NoDerivatives 2.0 UK: England & Wales:
You are free to use, copy, distribute and transmit the work or content in unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Makoto, Murata
Reuse is often the key selling point for XML authoring systems. This presentation examines reuse from various points of view, from the author’s to the developer’s, offering practical strategies for reuse of content. Markup design is discussed, as are necessary prerequisites for making such a system work. What should be reused, and when? How do you uniquely identify a resource, and what, exactly, is a resource anyway? How do you design a user interface that helps the author instead of hindering her? From a practical point of view, how do you design a publishing process that works?
 Today, I'd like to demonstrate two things. First, validation of Atom extensions is a mess. Second, although relaxing is the schema language for Atom fees, every year beats relaxing in validating Atom extensions. First, what is Atom? Okay, this is a very famous blog written by somebody in this room, Alex. Alex is there. This is probably the only reliable source of information about OXML at ISO. The reason I'd like to show this is it uses Atom to represent its fees. I'll show you. This is the Atom feed. XMN declaration, feed element, ID, title, updated link, etc. Alex plans weblog, author, generator. Okay, these things belong to this namespace, which is Atom. Here we see something different, blog channel, DC. They belong to different namespaces, and there appear to be more extensions. For example, Geo. Probably this is about his location. These things are not standardized in the original Atom RFC. These are extension elements. There are quite a few extensions of Atom. Some of them are IETF RFCs, other than just proprietary. But there are just so many extensions in the world. In the case of Alex's blog, there are about six extensions were used together. Google has its own extensions. Microsoft has its own extensions. Yahoo has its own extensions. There are just so many. And such extensions are typically represented by foreign elements or attributes. And this is not specific to Atom. Other formats, such as ODF version 1.1 and OXML, also use foreign elements and attributes. This is just a common practice. I should show you my Google calendar. Before this, I should show you the schema. This is the relaxing schema, which is contained in the original Atom RFC. I believe it was written by Noam. This is written in a schema language called relaxing. There are no other schemas for this Atom format. The relaxing schema is the only. Well, it says the root element is AtomFeed or AtomEntry. In fact, let's look at Alex's blog feed. The root element is a feed element. And this structure is written or controlled by this relaxing schema. A more interesting example is Google Calendar. I use Google Calendar always. I'm quite sure that some of you guys use Google Calendar as well. But they disclose the format as an AtomFeed. This represents the data my schedule. In fact, this shows my name in the Japanese characters. And Google uses quite a few extensions. Google Calendar, GData, OpenSearch. So although this looks like an AtomFeed, it actually represents my schedule information. Here you see Google Calendar elements. Okay. And we have observed more than one extension are used together. Google uses at least two. And Alex's blog uses more than five. I can imagine that this trend will become more apparent. People will use many extensions together. So, okay, this is nice. So we use extensions. We use Atom, which is an XML document. And we use relaxing for validation. This is nice. But what about validation of Atomic extensions? First, the original schema, Atom.rnc in the original AtomRFC, merely skips all extension elements and attributes, of course. Because that schema doesn't know anything about extensions. So far, so good. Okay, some extension RFCs, Atomic extension RFCs, provide schema fragments, relaxing schema fragments. However, such fragments are not invoked by the original Atom.rnc. What does this mean? This means that these schema fragments are never used. They are only for documentation. So Atomic extensions are not validated by these schema fragments. They are simply skipped. Some companies don't bother to write schema fragments. Only prose. So again, extensions are not validated. And I've seen that extensions actually have some errors which should be detected by validators. However, one can argue that Atom is still much better than the other formats. For example, ODF or XML both say they allow foreign elements and attributes. But their schema don't allow foreign elements or attributes. So if you will incorporate such foreign elements and attributes, you'll have validation errors. Okay. But Google is much better. When I wrote the original version of this my article two years ago, version one was not so great, but version two is great. They developed their own schema. I'll show you. Okay. This is Google Calendar Data API document. And it contains three schemas. One is a rewrite of the original Atom.rmc so that the Google extension elements such as GCal, GD are allowed. They also allow open search, I believe. Do they use Google? Okay. For example, Atom Calendar field can contain open search items per page. Start index. How do they allow Google Calendar information? Yes. So here's the Google Calendar selected property. This is a Google Calendar element. And it appears here. So they do rewrite Atom.rmc so that their extension elements are allowed and validated. Actually, these three schemas provided by Google are quite nice. They impose very tight restrictions. What kind of combinations are allowed? And sometimes they even disallow what was allowed in the original Atom.rmc because they are useless for them. Okay. So there are quite a few advantages. First, this is a great relaxing schema and it imposes tight restrictions. And now, as well as the top level Atom field things, Atom extension elements are also validated. This is quite nice. A way better than the other extensions. However, there are some disadvantages. How can we allow more? Do we have to, again, rewrite the Google schema? It's not easy. If we want, for example, allow three more extensions, then it will become prohibitively difficult. And I have tried, actually. I'm, of course, a relaxing hacker. I know a lot about relaxing customization techniques. I can write a relaxing schema that combines two or three extensions, but four is just difficult. And I know all minor videos relaxing very well about customization. Okay. So here comes NVIDIA. It is an ISO standard already. Namespace-based validation dispatching language. There are two key ideas in NVIDIA. First, we create a schema by combining sub-schemes. And each sub-schema is concerned about one or a few namespaces only. And different sub-schemas may be written in different schema languages. Simply put, an NVIDIA script is a collection of namespace schema players. So depending on the namespace, you choose a different schema. And maybe a different schema language. Key idea number two, divide and validate. Even the non-monolithic XML document, which contains many namespaces, you divide them into pieces using namespace boundaries and validate each of the validation candidates against some sub-schema. Okay, I'll demonstrate the processing model. The input is an NVIDIA script and an XML document, which contains more than one namespace. NVIDIA dispatcher creates some validation candidates and finds schemas, finds a schema for each of the validation candidates and then invokes validators for each of the validation candidates. Okay, I'm going to show this XML document as an example. These two colors represent two namespaces. So in this document, we have two namespaces. And this thing, everything appears in red. This is the validation candidate and will be validated against some schema. In the case of AtomFee, this is Atom.rmc. And these elements appear in the original Atom namespace. Okay, these things are proprietary extensions or standardized extensions. They have different namespaces and there are some different schemas and we can find such schemas from the namespace. And we validate these small validation candidates independently. One way to implement NVIDIA is to create a dispatcher of SACS events. NVIDIA engine receives a sequence of SACS events and dispatch these events to different validators. But it is certainly possible to use DOM for implementing NVIDIA or I believe it should be possible to implement a pull parser for implementing NVIDIA. Okay, who uses NVIDIA? OXML path 3 markup compatibility and extensions uses NVIDIA. And ODEV version 1.2 may use NVIDIA. This is not decided as far as I know, but there is a proposal. And I believe ILCA is using this for WFCE. Here it comes. And SVG uses this. And I recently found that open publication structure, this is about ebook, they use NVIDIA. And there are quite a few NVIDIA implementations already. Most of them are written in Java, but one is written in C sharp. Okay, given an atom, what do we do using NVIDIA? First, we don't have to change atom.rnc at all. We use it as is. Okay, given an atom field document, we first eliminate, remove all extension elements, and then validate the document against the original atom.rnc. And the extension elements are validated against different schemas. I'll show you the NVIDIA script. How many more minutes do I have? 40? 40? 20. Okay. Okay, this is the NVIDIA script. Since I have a lot of time, I'm going to explain this in detail. First, we begin with the mode root. Suppose we encounter an element of this name space, the atom name space. Then we validate these elements against atom.rnc, which is generated from atom.rnc. And when we encounter some foreign elements which appear as children of field elements, we do something different. Excuse me. When we encounter open search elements, we use open search 11.rng for validating that open search elements. And when we encounter Google name space, we use gd.rng. But within this Google elements, we might have entry link element, which in turn contains the original atom name space elements. Sorry, Google extensions allow embedded atom fees. Such embedded atom fees, sorry, atom entries are validated against atom.nn3.rng. And this appear in the same original name space. I'm not going to explain this, but I'm going to explain this. This is about Google Calendar. And extension elements of this name space are validated against this relaxing schema. This is quite, well, it becomes a bit lengthy, but it is quite easy to understand. Well, I didn't explain the details of the NVDA specification, but it allows you to do different things depending on the context. Because sometimes you want to allow extension elements only as children of, for example, feed elements. Details of these solutions are provided in the paper. The paper is written in step-by-step style, so it shouldn't be difficult to learn this technique. The first one is extremely simple. Okay, let's go back to the slide. Okay, advantages and disadvantages. First, it is not difficult to add more extensions. If we just rely on relaxing, adding four extensions is prohibitively difficult. But in the case of NVDA, it is doable. And even when RNC evolves, we don't have to change our NVDA script. It's just a thin layer on top of relaxing validation. And now, atomic extensions are not only skipped, but also validated against extension schemas. But there are some disadvantages. The biggest disadvantage is validation becomes somewhat loose, because this approach can't capture mutual interactions between different extensions. If you want to capture such mutual interactions, we have to rely on relaxing in the case of ATOM. So there is a trade-off. When you want to impose tight restrictions on mutual interactions, you have to rely on relaxing. But when you are ready to give up such tight restrictions, you can rely on NVDA and don't have to be annoyed by minor details of relaxing. Oops, the last line is a mistake, sorry. I already have the last slide. How many more minutes do I have? 15 minutes. So many. Sorry. But I'd like to welcome a lot of comments and questions. Before that, probably I should explain the Google Schema more. Google has quite a few schemas. They provide three schemas for Google Calendar only. And Google has lots of extensions. Google Calendar API is just one of them. They have many more, I believe. They have so many APIs. Financed Data API, for example. And I believe this one also provides a rewrite of ATOM.RMC. I'm not sure I can find it right now, but when I checked the last time, I find quite a few schemas. They really create relaxing schemas for the extensions. I believe they have done a very good work. However, I'm not just convinced that this scales. I've already published the first version of my paper two years ago. There are documents of some validation problems. And such problems are revealed by my NVDA script. And I pointed out that problem in my paper. It appears that later they fixed the bug and created these schemas. So I do believe that validation is important. And other organizations which propose extensions of ATOM should also care validation. Do you want to say something about that? No? You're not involved in it anymore, I see. Okay. I'd like to have a lot of questions and comments. More on my work, questions now. And perhaps if you don't mind, you can use it. Unfortunately, it's a little bit like a video. You can ask Paul because I think that might be, for example, interesting to hear how the new version of the model, whether it's an ATOM version or a new version of the model, there are a lot of potential problems in it. Okay. Let me point out one issue in the ATOM.inc. Well, depending on attribute values, it allows different models. And this was not possible in XSG version one. In version one.1, depending on attribute values. I'm asking. Well, depending on attribute values, we want to allow different content models. And ATOM.rnc does that. Yeah, that's 100% because we don't want to run it. Okay. Then the next issue is wildcard. Wildcard is a headache even for relaxing hackers. And it is a bigger headache for XSG hackers because of the UPC constraint. Will it be relaxed? Yeah, so the cool thing is that you want to run the model with it. And you can have actually a specific requirement for the wildcard process. And if you have a requirement for the wildcard process, you can run it. So the wildcard process is not allowed to open up. Mm-hmm. Well, does this mean, well, the UPC constraint is just abandoned totally? I don't know. So you can set it to layout, but the question is, you know, the process is wildcard. Okay. Mm-hmm, relaxings allow ambiguous content models, of course. But still, well, when we try to use wildcards together with specific content models, we sometimes have very harmful ambiguity. In other words, when we try to validate extensions, we sometimes allow wildcards to skip it. So we have to be very careful. And I believe that, well, XST version 1.1 will have that problem. Schema authors have to be careful, right? Oh, yeah, I don't think it's a big problem. Mm-hmm. Something I was going to ask you, I just want to clear up about whether the implementable content model allows the extension of the format, so whether the NVDL introduces it. Okay. There are three options in NVDL. A, foreign elements and attributes are just removed. B, you will remove foreign elements, but in place of such foreign elements, you introduce placeholder elements. So your component schema has to allow such placeholder elements. C, you don't remove foreign elements and attributes. You might want to validate such foreign elements and attributes against different schemas, but still the main thing will continue to have the foreign elements and attributes. And your schema should have wild card elements so that these things are allowed. So there are three options. The first option, which means foreign things are just removed, is easy. However, you will lose control because you can specify fair in your schema such elements are extension things are allowed. The other options are more difficult, but it allows tighter control. But even when you rely on the first option, you have a context element. So you can say, okay, we allow extension elements only as children of this element, in the case of atom feeds, atom entries. Is there any other question? I'm sorry about that. Well, there are quite a few tutorial documents right now. JNVDL manual. Well, who is the author of JNVDL? Is he here in this room? No? Oh. You've provided a tutorial on the part of your... I'm here from Akutian to order OMEDL instrumentation. Okay. Yes. Yes. Yes. I should show you the URL of his tutorial. There is a website, nvdl.org, which is maintained by Ken Holman, who is also here in this room. And this tutorial... This is a zip file containing PowerPoint document as well as lots of examples. So this is one of the nvdl tutorials, and there are quite a few other tutorials. JNVDL manual has a tutorial, and they... Well, my memory is not so great. How many tutorials do we have? One, two... I believe there are four now. Let me check. I should provide more links in this section, tutorials for nvdl. There are at least three. I'll do... Yuka, do you want to say something about JNVDL? Oh. Okay. Okay. Yes. Yes. That part is hard. Yes. If you really create validation candidates as different XML documents, they will certainly have different line numbers. Sorry. Alex, will we discuss in WG1 about this? There is one commercial thing which uses nvdl now. This is E-book, what used to be called E-book. This is serious. They do use nvdl. I'm searching for... Open publication structure. Open e-book has three things. OPS, OPS, OCR. They use relaxing. This one uses nvdl. Sorry. Open publication structure, OPS, version 2. Relationship to nvdl. This one uses nvdl. Yes, this is the schema. They use nvdl for embedding XHTML and SVG and that making your schema complicated. Probably this is the only commercial use of nvdl. This is not by one company, but this is used for real business. I don't know how successful this spec is. But this spec was built two years ago, or one year ago, two years ago almost. But only recently we start to use non-monolithic documents very heavily. In the case of Atomic Yes. In the case of ODA and OXML, probably we will do so. But not very common yet. So I believe that the prime time of nvdl is to come. No other schema languages can compete with nvdl. This is a dedicated solution for this problem. We have time for one more question. Is there anyone else? Thank you very much. Thank you.
 Today, I'd like to demonstrate two things.  First, validation of Atom extensions is a mess.  Second, although relaxing is the schema language for Atom fees,  every year beats relaxing in validating Atom extensions.  First, what is Atom?  Okay, this is a very famous blog written by somebody in this room, Alex.  Alex is there.  This is probably the only reliable source of information about OXML at ISO.  The reason I'd like to show this is it uses Atom to represent its fees.  I'll show you.  This is the Atom feed.  XMN declaration, feed element, ID, title, updated link, etc.  Alex plans weblog, author, generator.  Okay, these things belong to this namespace, which is Atom.  Here we see something different, blog channel, DC.  They belong to different namespaces, and there appear to be more extensions.  For example, Geo.  Probably this is about his location.  These things are not standardized in the original Atom RFC.  These are extension elements.  There are quite a few extensions of Atom.  Some of them are IETF RFCs, other than just proprietary.  But there are just so many extensions in the world.  In the case of Alex's blog, there are about six extensions were used together.  Google has its own extensions.  Microsoft has its own extensions.  Yahoo has its own extensions.  There are just so many.  And such extensions are typically represented by foreign elements or attributes.  And this is not specific to Atom.  Other formats, such as ODF version 1.1 and OXML, also use foreign elements and attributes.  This is just a common practice.  I should show you my Google calendar.  Before this, I should show you the schema.  This is the relaxing schema, which is contained in the original Atom RFC.  I believe it was written by Noam.  This is written in a schema language called relaxing.  There are no other schemas for this Atom format.  The relaxing schema is the only.  Well, it says the root element is AtomFeed or AtomEntry.  In fact, let's look at Alex's blog feed.  The root element is a feed element.  And this structure is written or controlled by this relaxing schema.  A more interesting example is Google Calendar.  I use Google Calendar always.  I'm quite sure that some of you guys use Google Calendar as well.  But they disclose the format as an AtomFeed.  This represents the data my schedule.  In fact, this shows my name in the Japanese characters.  And Google uses quite a few extensions.  Google Calendar, GData, OpenSearch.  So although this looks like an AtomFeed,  it actually represents my schedule information.  Here you see Google Calendar elements.  Okay.  And we have observed more than one extension are used together.  Google uses at least two.  And Alex's blog uses more than five.  I can imagine that this trend will become more apparent.  People will use many extensions together.  So, okay, this is nice.  So we use extensions.  We use Atom, which is an XML document.  And we use relaxing for validation.  This is nice.  But what about validation of Atomic extensions?  First, the original schema, Atom.rnc in the original AtomRFC,  merely skips all extension elements and attributes, of course.  Because that schema doesn't know anything about extensions.  So far, so good.  Okay, some extension RFCs, Atomic extension RFCs,  provide schema fragments, relaxing schema fragments.  However, such fragments are not invoked by the original Atom.rnc.  What does this mean?  This means that these schema fragments are never used.  They are only for documentation.  So Atomic extensions are not validated by these schema fragments.  They are simply skipped.  Some companies don't bother to write schema fragments.  Only prose.  So again, extensions are not validated.  And I've seen that extensions actually have some errors  which should be detected by validators.  However, one can argue that Atom is still much better than the other formats.  For example, ODF or XML both say they allow foreign elements and attributes.  But their schema don't allow foreign elements or attributes.  So if you will incorporate such foreign elements and attributes,  you'll have validation errors.  Okay.  But Google is much better.  When I wrote the original version of this my article two years ago,  version one was not so great, but version two is great.  They developed their own schema.  I'll show you.  Okay.  This is Google Calendar Data API document.  And it contains three schemas.  One is a rewrite of the original Atom.rmc so that the Google extension elements  such as GCal, GD are allowed.  They also allow open search, I believe.  Do they use Google?  Okay. For example, Atom Calendar field can contain open search items per page.  Start index.  How do they allow Google Calendar information?  Yes.  So here's the Google Calendar selected property.  This is a Google Calendar element.  And it appears here.  So they do rewrite Atom.rmc so that their extension elements are allowed  and validated.  Actually, these three schemas provided by Google are quite nice.  They impose very tight restrictions.  What kind of combinations are allowed?  And sometimes they even disallow what was allowed in the original Atom.rmc  because they are useless for them.  Okay.  So there are quite a few advantages.  First, this is a great relaxing schema and it imposes tight restrictions.  And now, as well as the top level Atom field things,  Atom extension elements are also validated.  This is quite nice.  A way better than the other extensions.  However, there are some disadvantages.  How can we allow more?  Do we have to, again, rewrite the Google schema?  It's not easy.  If we want, for example, allow three more extensions,  then it will become prohibitively difficult.  And I have tried, actually.  I'm, of course, a relaxing hacker.  I know a lot about relaxing customization techniques.  I can write a relaxing schema that combines two or three extensions,  but four is just difficult.  And I know all minor videos relaxing very well about customization.  Okay.  So here comes NVIDIA.  It is an ISO standard already.  Namespace-based validation dispatching language.  There are two key ideas in NVIDIA.  First, we create a schema by combining sub-schemes.  And each sub-schema is concerned about one or a few namespaces only.  And different sub-schemas may be written in different schema languages.  Simply put, an NVIDIA script is a collection of namespace schema players.  So depending on the namespace, you choose a different schema.  And maybe a different schema language.  Key idea number two, divide and validate.  Even the non-monolithic XML document, which contains many namespaces,  you divide them into pieces using namespace boundaries  and validate each of the validation candidates against some sub-schema.  Okay, I'll demonstrate the processing model.  The input is an NVIDIA script and an XML document, which contains more than one namespace.  NVIDIA dispatcher creates some validation candidates  and finds schemas, finds a schema for each of the validation candidates  and then invokes validators for each of the validation candidates.  Okay, I'm going to show this XML document as an example.  These two colors represent two namespaces.  So in this document, we have two namespaces.  And this thing, everything appears in red.  This is the validation candidate and will be validated against some schema.  In the case of AtomFee, this is Atom.rmc.  And these elements appear in the original Atom namespace.  Okay, these things are proprietary extensions or standardized extensions.  They have different namespaces and there are some different schemas  and we can find such schemas from the namespace.  And we validate these small validation candidates independently.  One way to implement NVIDIA is to create a dispatcher of SACS events.  NVIDIA engine receives a sequence of SACS events and dispatch these events to different validators.  But it is certainly possible to use DOM for implementing NVIDIA  or I believe it should be possible to implement a pull parser for implementing NVIDIA.  Okay, who uses NVIDIA?  OXML path 3 markup compatibility and extensions uses NVIDIA.  And ODEV version 1.2 may use NVIDIA.  This is not decided as far as I know, but there is a proposal.  And I believe ILCA is using this for WFCE.  Here it comes.  And SVG uses this.  And I recently found that open publication structure, this is about ebook, they use NVIDIA.  And there are quite a few NVIDIA implementations already.  Most of them are written in Java, but one is written in C sharp.  Okay, given an atom, what do we do using NVIDIA?  First, we don't have to change atom.rnc at all.  We use it as is.  Okay, given an atom field document, we first eliminate, remove all extension elements,  and then validate the document against the original atom.rnc.  And the extension elements are validated against different schemas.  I'll show you the NVIDIA script.  How many more minutes do I have?  40?  40?  20.  Okay.  Okay, this is the NVIDIA script.  Since I have a lot of time, I'm going to explain this in detail.  First, we begin with the mode root.  Suppose we encounter an element of this name space, the atom name space.  Then we validate these elements against atom.rnc, which is generated from atom.rnc.  And when we encounter some foreign elements which appear as children of field elements,  we do something different.  Excuse me. When we encounter open search elements,  we use open search 11.rng for validating that open search elements.  And when we encounter Google name space, we use gd.rng.  But within this Google elements, we might have entry link element,  which in turn contains the original atom name space elements.  Sorry, Google extensions allow embedded atom fees.  Such embedded atom fees, sorry, atom entries are validated against atom.nn3.rng.  And this appear in the same original name space.  I'm not going to explain this, but I'm going to explain this.  This is about Google Calendar.  And extension elements of this name space are validated against this relaxing schema.  This is quite, well, it becomes a bit lengthy, but it is quite easy to understand.  Well, I didn't explain the details of the NVDA specification,  but it allows you to do different things depending on the context.  Because sometimes you want to allow extension elements only as children of, for example, feed elements.  Details of these solutions are provided in the paper.  The paper is written in step-by-step style, so it shouldn't be difficult to learn this technique.  The first one is extremely simple.  Okay, let's go back to the slide.  Okay, advantages and disadvantages.  First, it is not difficult to add more extensions.  If we just rely on relaxing, adding four extensions is prohibitively difficult.  But in the case of NVDA, it is doable.  And even when RNC evolves, we don't have to change our NVDA script.  It's just a thin layer on top of relaxing validation.  And now, atomic extensions are not only skipped, but also validated against extension schemas.  But there are some disadvantages.  The biggest disadvantage is validation becomes somewhat loose,  because this approach can't capture mutual interactions between different extensions.  If you want to capture such mutual interactions, we have to rely on relaxing in the case of ATOM.  So there is a trade-off.  When you want to impose tight restrictions on mutual interactions, you have to rely on relaxing.  But when you are ready to give up such tight restrictions, you can rely on NVDA and don't have to be annoyed by minor details of relaxing.  Oops, the last line is a mistake, sorry.  I already have the last slide.  How many more minutes do I have?  15 minutes.  So many.  Sorry.  But I'd like to welcome a lot of comments and questions.  Before that, probably I should explain the Google Schema more.  Google has quite a few schemas.  They provide three schemas for Google Calendar only.  And Google has lots of extensions.  Google Calendar API is just one of them.  They have many more, I believe.  They have so many APIs.  Financed Data API, for example.  And I believe this one also provides a rewrite of ATOM.RMC.  I'm not sure I can find it right now, but when I checked the last time, I find quite a few schemas.  They really create relaxing schemas for the extensions.  I believe they have done a very good work.  However, I'm not just convinced that this scales.  I've already published the first version of my paper two years ago.  There are documents of some validation problems.  And such problems are revealed by my NVDA script.  And I pointed out that problem in my paper.  It appears that later they fixed the bug and created these schemas.  So I do believe that validation is important.  And other organizations which propose extensions of ATOM should also care validation.  Do you want to say something about that?  No?  You're not involved in it anymore, I see.  Okay.  I'd like to have a lot of questions and comments.  More on my work, questions now.  And perhaps if you don't mind, you can use it.  Unfortunately, it's a little bit like a video.  You can ask Paul because I think that might be, for example, interesting to hear how the new version of the model,  whether it's an ATOM version or a new version of the model,  there are a lot of potential problems in it.  Okay.  Let me point out one issue in the ATOM.inc.  Well, depending on attribute values, it allows different models.  And this was not possible in XSG version one.  In version one.1, depending on attribute values.  I'm asking.  Well, depending on attribute values, we want to allow different content models.  And ATOM.rnc does that.  Yeah, that's 100% because we don't want to run it.  Okay.  Then the next issue is wildcard.  Wildcard is a headache even for relaxing hackers.  And it is a bigger headache for XSG hackers because of the UPC constraint.  Will it be relaxed?  Yeah, so the cool thing is that you want to run the model with it.  And you can have actually a specific requirement for the wildcard process.  And if you have a requirement for the wildcard process,  you can run it.  So the wildcard process is not allowed to open up.  Mm-hmm.  Well, does this mean, well, the UPC constraint is just abandoned totally?  I don't know.  So you can set it to layout, but the question is, you know,  the process is wildcard.  Okay.  Mm-hmm, relaxings allow ambiguous content models, of course.  But still, well, when we try to use wildcards together with specific content models,  we sometimes have very harmful ambiguity.  In other words, when we try to validate extensions,  we sometimes allow wildcards to skip it.  So we have to be very careful.  And I believe that, well, XST version 1.1 will have that problem.  Schema authors have to be careful, right?  Oh, yeah, I don't think it's a big problem.  Mm-hmm.  Something I was going to ask you, I just want to clear up  about whether the implementable content model  allows the extension of the format, so whether the NVDL introduces it.  Okay.  There are three options in NVDL.  A, foreign elements and attributes are just removed.  B, you will remove foreign elements,  but in place of such foreign elements, you introduce placeholder elements.  So your component schema has to allow such placeholder elements.  C, you don't remove foreign elements and attributes.  You might want to validate such foreign elements and attributes against different schemas,  but still the main thing will continue to have the foreign elements and attributes.  And your schema should have wild card elements so that these things are allowed.  So there are three options.  The first option, which means foreign things are just removed, is easy.  However, you will lose control because you can specify fair in your schema  such elements are extension things are allowed.  The other options are more difficult, but it allows tighter control.  But even when you rely on the first option, you have a context element.  So you can say, okay, we allow extension elements only as children of this element,  in the case of atom feeds, atom entries.  Is there any other question?  I'm sorry about that.  Well, there are quite a few tutorial documents right now.  JNVDL manual.  Well, who is the author of JNVDL?  Is he here in this room?  No?  Oh.  You've provided a tutorial on the part of your...  I'm here from Akutian to order OMEDL instrumentation.  Okay.  Yes.  Yes.  Yes.  I should show you the URL of his tutorial.  There is a website, nvdl.org, which is maintained by Ken Holman,  who is also here in this room.  And this tutorial...  This is a zip file containing PowerPoint document as well as lots of examples.  So this is one of the nvdl tutorials, and there are quite a few other tutorials.  JNVDL manual has a tutorial, and they...  Well, my memory is not so great.  How many tutorials do we have?  One, two... I believe there are four now.  Let me check.  I should provide more links in this section, tutorials for nvdl.  There are at least three.  I'll do...  Yuka, do you want to say something about JNVDL?  Oh.  Okay.  Okay.  Yes.  Yes. That part is hard.  Yes.  If you really create validation candidates as different XML documents,  they will certainly have different line numbers.  Sorry.  Alex, will we discuss in WG1 about this?  There is one commercial thing which uses nvdl now.  This is E-book, what used to be called E-book.  This is serious.  They do use nvdl.  I'm searching for...  Open publication structure.  Open e-book has three things.  OPS, OPS, OCR.  They use relaxing.  This one uses nvdl.  Sorry.  Open publication structure, OPS, version 2.  Relationship to nvdl.  This one uses nvdl.  Yes, this is the schema.  They use nvdl for embedding XHTML and SVG  and that making your schema complicated.  Probably this is the only commercial use of nvdl.  This is not by one company, but this is used for real business.  I don't know how successful this spec is.  But this spec was built two years ago, or one year ago,  two years ago almost.  But only recently we start to use non-monolithic documents very heavily.  In the case of Atomic Yes.  In the case of ODA and OXML, probably we will do so.  But not very common yet.  So I believe that the prime time of nvdl is to come.  No other schema languages can compete with nvdl.  This is a dedicated solution for this problem.  We have time for one more question.  Is there anyone else?  Thank you very much.  Thank you.
Full_validation_of_Atom_feeds_containing_extensions_using_NVDL_2_0_635.png Full_validation_of_Atom_feeds_containing_extensions_using_NVDL_2_636_3011.png Full_validation_of_Atom_feeds_containing_extensions_using_NVDL_2_3012_4871.png Full_validation_of_Atom_feeds_containing_extensions_using_NVDL_2_4872_5363.png Full_validation_of_Atom_feeds_containing_extensions_using_NVDL_2_5364_6083.png Full_validation_of_Atom_feeds_containing_extensions_using_NVDL_2_6084_7211.png Full_validation_of_Atom_feeds_containing_extensions_using_NVDL_2_7212_7583.png Full_validation_of_Atom_feeds_containing_extensions_using_NVDL_2_7584_12887.png Full_validation_of_Atom_feeds_containing_extensions_using_NVDL_2_12888_13235.png Full_validation_of_Atom_feeds_containing_extensions_using_NVDL_2_13236_13907.png Full_validation_of_Atom_feeds_containing_extensions_using_NVDL_2_13908_14255.png Full_validation_of_Atom_feeds_containing_extensions_using_NVDL_2_14256_14411.png Full_validation_of_Atom_feeds_containing_extensions_using_NVDL_2_14412_20927.png Full_validation_of_Atom_feeds_containing_extensions_using_NVDL_2_20928_23699.png Full_validation_of_Atom_feeds_containing_extensions_using_NVDL_2_23700_26159.png Full_validation_of_Atom_feeds_containing_extensions_using_NVDL_2_26160_29807.png Full_validation_of_Atom_feeds_containing_extensions_using_NVDL_2_29808_29855.png Full_validation_of_Atom_feeds_containing_extensions_using_NVDL_2_29856_30347.png Full_validation_of_Atom_feeds_containing_extensions_using_NVDL_2_30348_31571.png Full_validation_of_Atom_feeds_containing_extensions_using_NVDL_2_31572_32195.png Full_validation_of_Atom_feeds_containing_extensions_using_NVDL_2_32196_36983.png Full_validation_of_Atom_feeds_containing_extensions_using_NVDL_2_36984_37271.png Full_validation_of_Atom_feeds_containing_extensions_using_NVDL_2_37272_37607.png Full_validation_of_Atom_feeds_containing_extensions_using_NVDL_2_37608_38003.png Full_validation_of_Atom_feeds_containing_extensions_using_NVDL_2_38004_38411.png Full_validation_of_Atom_feeds_containing_extensions_using_NVDL_2_38412_51047.png Full_validation_of_Atom_feeds_containing_extensions_using_NVDL_2_51048_55907.png Full_validation_of_Atom_feeds_containing_extensions_using_NVDL_2_55908_56327.png Full_validation_of_Atom_feeds_containing_extensions_using_NVDL_2_56328_56507.png Full_validation_of_Atom_feeds_containing_extensions_using_NVDL_2_56508_61009.png