Re: NVDL, SVG validation (Was: first questions on validator.nu)

> No, I don't think so either, since nvdl has its rules and triggers  
> based on namespaces, as far as I can tell. This would mean that using  
> a different schema for different versions or profiles of a language  
> using one namespace (as SVG, or indeed xhtml, do) would need a pre- 
> parse. In the case of SVG it's not that bad since the version/ 
> baseProfile information is on the root element, but it does need an  
> xml-preparsing.
> 
> I wonder if there's a part of nvdl that does that, and which I haven't  
> found yet.

NVDL itself doesn't have provision for this. But you are not first with
such requirement. Our implementation JNVDL has extension for this, see:

http://jnvdl.sourceforge.net/extensions.html#extensions-usewhen

I think that something very similar will get into next official version
of NVDL language. There have been discussion about similar NVDL feature
in the past and I have intended to restart this discussion on JTC1/SC34
(body which maintains NVDL) adter other NVDL errata are processed.

>> Ideally, I'd like to see a single unified SVG spec whose latest  
>> version the validator would track. That is, I'd prefer an "SVG5"  
>> schema over profiles.
> 
> I suppose there was a good reason to create profiles for small  
> devices... Anyway, that would be developer feedback for the SVG  
> working group to hear.

It is very common to work with subset languages/profiles. Using subset
you can limit your authors or impose various restrictions to accommodate
limitations of your toolchain, but your documents are still compatible
with master/full language. My daily job is creating subsets of DocBook
-- so SVG is not the only language which need this.

For example you can have renderer that turn SVG into PDF file intended
for print. You might want to validate that SVG file is not using any
animations and other dynamic effects that would be lost on paper.

>> It might be that the NVDL part of oNVDL allows something like this  
>> already. I haven't investigated yet. I have considered this issue,  
>> though, and I am planning on punching a hole in the XHTML5 schema  
>> for embedded RDF, for example.
>
> I think that's be a perfect job for nvdl. See this example in the  
> jnvdl documentation:
> http://jnvdl.sourceforge.net/tutorial.html#d4e311

Indeed. Managing such holes for more complex compound documents can be
very tricky, see:

http://2007.xtech.org/public/schedule/paper/76#validation

Using RELAX NG patterns for this is OK for combination of two or three
languages, but for more languages it's really not nice. Also resulting
schema is very big and some validators can have problem with it.

>> I guess the SVG schema should get that hole, too. I have also  
>> considered an option to filter out unknown namespaces, but I'm not  
>> sure if it is good to open such "anything goes" holes in a validator.
> 
> Not a big fan of it myself, but there is an audience for it. I've  
> heard it asked more than a few times now: a number of hackers want the  
> right to play with the X in XML *and* get validation.

I think that the biggest mistake of XHTML is its definition of "strictly
conformant document" which prevents extensibility. It's perfectly OK to
put custom elements/attributes from other namespaces almost everywhere
in almost any XML document. For example our Relaxed
(http://relaxed.vse.cz) validator (RELAX NG + Schematron based) allows
it -- basic schema for HTML/XHTML simply ignores everything which is not
in XHTML namespace. But you can also use more strict version of schema
which rejects everything what is not in XHTML namespace.

					Jirka

-- 
------------------------------------------------------------------
  Jirka Kosek      e-mail: jirka@kosek.cz      http://xmlguru.cz
------------------------------------------------------------------
       Professional XML consulting and training services
  DocBook customization, custom XSLT/XSL-FO document processing
------------------------------------------------------------------
 OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 member
------------------------------------------------------------------